Fake Door Test কী: Feature বানানোর আগে Interest মাপার পদ্ধতি

নতুন একটি Feature নিয়ে টিমের সবাই উৎসাহী। Design তৈরি হলো, Development শুরু হলো, কয়েক সপ্তাহ বা মাস পর Feature-টি চালুও হলো। সমস্যা দেখা দিল এরপর—User-রা সেটি তেমন ব্যবহারই করছে না। অর্থাৎ, সমাধানটি তৈরি করার আগে আসল চাহিদা কতটা ছিল, সেটিই ঠিকমতো যাচাই করা হয়নি।

Fake Door Test এই ঝুঁকি কমানোর একটি প্রাথমিক পদ্ধতি। পুরো Feature তৈরি না করেই Button, Menu item, Landing page বা অন্য কোনো বাস্তবসম্মত entry point দেখিয়ে দেখা হয় User সেটিতে আগ্রহ দেখাচ্ছে কি না। User ক্লিক করলে তাকে দ্রুত জানিয়ে দেওয়া হয় যে Feature-টি এখনো চালু হয়নি। সেই interaction থেকে Product Team একটি গুরুত্বপূর্ণ প্রশ্নের উত্তর খোঁজে—মানুষ কি সত্যিই এই সুবিধাটি ব্যবহার করার চেষ্টা করছে?

তবে একটি বিষয় শুরুতেই পরিষ্কার রাখা দরকার: ক্লিক পাওয়া মানেই Feature সফল হবে না। Fake Door Test মূলত interest বা intent-এর প্রাথমিক signal দেয়; বাস্তব ব্যবহার, সন্তুষ্টি, retention কিংবা অর্থ দিয়ে কিনতে রাজি হওয়ার প্রমাণ দেয় না।

Fake Door Test আসলে কী?

Fake Door Test, যাকে Painted Door Test-ও বলা হয়, এমন একটি validation পদ্ধতি যেখানে এখনো তৈরি হয়নি এমন Feature বা Product-এর একটি বিশ্বাসযোগ্য প্রবেশপথ User-এর সামনে রাখা হয়। এটি দেখতে বাস্তব Feature-এর অংশের মতো হতে পারে, কিন্তু এর পেছনে সম্পূর্ণ কার্যকারিতা থাকে না।

ধরা যাক, একটি Project Management সফটওয়্যারে এখনো “AI Meeting Summary” নেই। Product Team সরাসরি Feature বানানোর বদলে নির্দিষ্ট User-দের Dashboard-এ একটি Button দেখাল:

Generate AI Meeting Summary

Button-এ ক্লিক করার পর সরাসরি একটি বার্তা দেখা গেল:

“এই Feature-টি এখনো চালু হয়নি। আমরা এটি নিয়ে কাজ করার সম্ভাবনা যাচাই করছি। Early access পেতে চাইলে জানাতে পারেন।”

এরপর Team দেখতে পারে:

• কতজন User Button-টি দেখেছে;
• কতজন ক্লিক করেছে;
• কোন ধরনের User বেশি ক্লিক করেছে;
• ক্লিককারীদের কতজন Early access বা Waitlist-এ আগ্রহ দেখিয়েছে;
• একই User বারবার চেষ্টা করেছে কি না।

অর্থাৎ, Feature-এর “ঘর” বানানোর আগে দরজায় কেউ আসছে কি না দেখা হচ্ছে।

কেন শুধু User-কে জিজ্ঞেস করলেই যথেষ্ট নয়

User interview বা Survey-এর প্রয়োজন আছে। সমস্যা হলো, মানুষ কী বলছে আর সুযোগ সামনে এলে কী করছে—দুটো সব সময় একই তথ্য দেয় না।

কেউ Interview-তে বলতে পারে, “এই Feature থাকলে অবশ্যই ব্যবহার করব।” বাস্তবে Product-এর মধ্যে সেই অপশন দেখেও সে ক্লিক না করতে পারে। আবার এমন User-ও থাকতে পারে, যে কখনো Feature-টির কথা চায়নি, কিন্তু Button দেখেই সেটি ব্যবহার করতে চেষ্টা করেছে।

Productboard-এর Need Validation Framework-এও Fake Door, Waitlist এবং সরাসরি প্রশ্নকে User-এর willingness to act যাচাইয়ের আলাদা উপায় হিসেবে রাখা হয়েছে। অর্থাৎ, বক্তব্যের পাশাপাশি আচরণগত signal দেখাও দরকার।

তাই Fake Door Test User Research-এর বিকল্প নয়। বরং Survey বা Interview থেকে পাওয়া ধারণার পাশে একটি behavioral signal যোগ করে।

আরও পড়ুনঃ Competitor নেই মানেই Opportunity কি না: Market Validation-এর বাস্তবতা

Fake Door Test, MVP ও A/B Testing এক জিনিস নয়

এই তিনটি ধারণা কাছাকাছি Product Development পর্যায়ে ব্যবহার হতে পারে বলে সহজেই গুলিয়ে যায়।

বিশেষ করে Fake Door Test এবং A/B Testing-কে বিপরীত পদ্ধতি ভাবা ঠিক নয়। A/B Testing হলো দুটি version-এর performance তুলনা করার experiment methodology। Optimizely-র সংজ্ঞাতেও A/B Testing-কে দুটি version তুলনার পদ্ধতি হিসেবে ব্যাখ্যা করা হয়েছে।

চাইলে Fake Door-এর Button copy নিয়েও A/B Test চালানো যায়। যেমন একটি group দেখতে পারে “Create Automated Report”, অন্যটি “Save Time with Automated Reports”। তখন Fake Door demand signal দিচ্ছে, আর A/B design বলছে কোন presentation তুলনামূলক বেশি interaction আনছে।

MVP আরও এক ধাপ এগিয়ে। সেখানে User অন্তত Product বা Feature-এর কার্যকর সংস্করণ ব্যবহার করতে পারে। ফলে Fake Door-এর “চেষ্টা করার ইচ্ছা” থেকে MVP পর্যায়ে গিয়ে “বাস্তবে ব্যবহার ও value পাওয়া” যাচাই করা যায়।

কোন পরিস্থিতিতে Fake Door Test কাজে লাগে

সব Product idea-র সামনে Fake Door বসানো দরকার নেই। সবচেয়ে কার্যকর হয় যখন Development cost যথেষ্ট, অথচ demand নিয়ে অনিশ্চয়তা আছে।

বড় Feature তৈরির আগে

ধরা যাক একটি SaaS Product-এ advanced reporting module যোগ করতে কয়েকটি Sprint লাগবে। Existing User-দের মধ্যে কতজন সেটি চান, তার পরিষ্কার evidence নেই।

এ ক্ষেত্রে আগে relevant reporting User-দের কাছে একটি Fake Door দেখানো Development priority ঠিক করতে সাহায্য করতে পারে।

নতুন Product idea যাচাইয়ে

Existing Product না থাকলেও Landing page, Product card বা CTA দিয়ে একই নীতি প্রয়োগ করা যায়। তবে Traffic যেন সম্ভাব্য Target User থেকেই আসে—বন্ধু বা সহকর্মীদের ক্লিক দিয়ে market demand বোঝা যায় না।

কোন User segment বেশি আগ্রহী, তা বুঝতে

সামগ্রিক click rate-এর চেয়ে অনেক সময় segment বেশি মূল্যবান।

ধরা যাক মোট interaction কম, কিন্তু Agency account-এর মধ্যে আগ্রহ অনেক বেশি। তখন Feature-টি সবার জন্য না বানিয়ে Agency-focused offering হিসেবে আরও যাচাই করা যুক্তিসংগত হতে পারে।

Beta User খুঁজতে

যারা Fake Door-এ ক্লিক করেছেন, তাদের ইচ্ছা থাকলে Early access বা Beta programme-এ যোগ দেওয়ার সুযোগ দেওয়া যায়। এতে পরবর্তী qualitative research-এর জন্য বেশি প্রাসঙ্গিক User পাওয়া সম্ভব।

ধাপে ধাপে একটি Fake Door Test কীভাবে করবেন

১. প্রথমে যে অনুমানটি যাচাই করবেন, সেটি লিখুন

“User-রা Feature চাইবে”—এটি পরীক্ষাযোগ্য hypothesis নয়।

এর চেয়ে স্পষ্টভাবে লেখা যায়:

সক্রিয় Team account-এর User-দের সামনে automated client report অপশন দেখানো হলে তাদের একটি অর্থবহ অংশ সেটি ব্যবহার করার চেষ্টা করবে।

এখানে Target User এবং expected action দুটোই পরিষ্কার।

পরীক্ষা শুরু হওয়ার আগে কোন ফল পেলে পরবর্তী ধাপে যাবেন, সেটিও নির্ধারণ করুন। পরে ফল দেখে threshold বদলে ফেললে সিদ্ধান্তে পক্ষপাত ঢোকার ঝুঁকি বাড়ে। Fake Door testing guidance-এও success criteria আগে নির্ধারণ করার ওপর জোর দেওয়া হয়েছে।

সবার জন্য প্রযোজ্য কোনো “ভালো CTR” নেই। Feature কোথায় দেখানো হয়েছে, কতজন relevant User সেটি দেখেছে, তাদের বর্তমান workflow এবং Feature তৈরির খরচ—সবই সিদ্ধান্তে প্রভাব ফেলবে।

২. সঠিক User-দের সামনে Door দেখান

Enterprise Feature পরীক্ষা করতে free বা individual User-দের সবাইকে সেটি দেখালে data দুর্বল হতে পারে।

যাদের বাস্তবে Feature-টির প্রয়োজন হওয়ার কথা, তাদের বেছে নিন। যেমন:

• Export Feature → যারা নিয়মিত Data বা Report নিয়ে কাজ করে;
• Team permission → Multi-user account;
• Advanced analytics → নিয়মিত Dashboard User;
• Integration → সংশ্লিষ্ট workflow ব্যবহারকারী।

User lifecycle-ও গুরুত্বপূর্ণ। নতুন User যে advanced setting বোঝেনি, তার click না করা এবং Power User-এর click না করার অর্থ এক নয়।

৩. Door-টি বাস্তবসম্মত করুন, কিন্তু অতিরিক্ত প্রতিশ্রুতি দেবেন না

Button বা Menu item এমন জায়গায় রাখুন, যেখানে আসল Feature থাকলে User সেটি খুঁজত।

Label-ও পরিষ্কার হওয়া দরকার। “New Feature” বলার চেয়ে “Export as CSV” User-কে বেশি নির্দিষ্ট ধারণা দেয়।

এখানে বিশ্বাসযোগ্যতা ও সততার মধ্যে ভারসাম্য জরুরি। এমন ভাষা ব্যবহার করা ঠিক নয়, যাতে User মনে করেন Feature নিশ্চিতভাবে এখনই পাওয়া যাচ্ছে, অথচ ক্লিকের পর সম্পূর্ণ ভিন্ন কিছু দেখা যায়।

“Try automated reports now” বলার বদলে পরিস্থিতি অনুযায়ী “Interested in automated reports?” বা “Automated reports — coming soon” ধরনের ভাষা User expectation নিয়ন্ত্রণে রাখতে পারে।

৪. Click-এর পর সঙ্গে সঙ্গে পরিষ্কার করুন কী ঘটেছে

Fake Door-এর সবচেয়ে সংবেদনশীল অংশ এটি।

User ক্লিক করার পর blank page, error message বা অকার্যকর Button রেখে দেওয়া উচিত নয়। তাকে পরিষ্কারভাবে জানান:

• Feature এখনো available নয়;
• Team demand যাচাই করছে;
• চাইলে Early access বা update-এর জন্য আগ্রহ জানানো যাবে;
• আগের কাজে সহজে ফিরে যাওয়া যাবে।

Email দেওয়া বা Account তৈরি করা বাধ্যতামূলক করা উচিত নয়। Amplitude-এর Fake Door guidance-ও post-click disclosure এবং optional signup-এর ওপর জোর দেয়।

বিশেষ করে pricing test হলে Fake Door-কে বাস্তব checkout-এর মতো সাজিয়ে আসল অর্থ কেটে নেওয়া বা অপ্রয়োজনীয় payment information সংগ্রহ করা থেকে বিরত থাকাই নিরাপদ সম্পাদকীয় পদ্ধতি। এখানে উদ্দেশ্য demand signal নেওয়া, User-কে এমন transaction-এ নেওয়া নয় যার বিনিময়ে Product দেওয়া সম্ভব নয়।

৫. শুধু মোট Click গুনবেন না

সবচেয়ে সহজ metric হলো:

Click-through rate = Unique click করা User ÷ Fake Door দেখা Unique User × ১০০

ধরা যাক ২,০০০ relevant User Door দেখেছেন এবং ১২০ জন ক্লিক করেছেন। সে ক্ষেত্রে click-through rate হবে ৬%।

কিন্তু “৬% ভালো না খারাপ”—এই সিদ্ধান্ত শুধু সংখ্যাটি দেখে নেওয়া যাবে না।

আরও দেখুন:

• Unique click বনাম repeated click;
• কোন User segment বেশি ক্লিক করেছে;
• Door দেখার কত দ্রুত পর click এসেছে;
• Click-এর পর কতজন Waitlist-এ গেছে;
• কতজন feedback দিতে রাজি হয়েছে;
• কোন traffic source বা workflow থেকে interest এসেছে।

Repeated click শক্ত আগ্রহের signal হতে পারে, আবার User বিভ্রান্ত হয়েছে বলেও হতে পারে। সংখ্যার পাশে context দরকার।

ফল বেশি হলে কি Feature বানিয়ে ফেলবেন?

সরাসরি নয়।

Fake Door Test বলছে User দরজায় ঢোকার চেষ্টা করেছে। ভেতরের Product ব্যবহার করবে, নিয়মিত ব্যবহার করবে বা অর্থ দেবে—সেটি এখনো প্রমাণিত হয়নি।

High interest পেলে পরবর্তী ধাপ হতে পারে:

Fake Door → User interview → Prototype → MVP → বাস্তব usage measurement

ক্লিককারীদের একটি অংশের সঙ্গে কথা বলুন। তারা কেন Feature চেয়েছে, বর্তমানে কী workaround ব্যবহার করছে, সমস্যাটি কত ঘন ঘন হয় এবং সমাধানটির জন্য তারা কী ত্যাগ করতে রাজি—এসব বোঝার চেষ্টা করুন।

Painted Door guidance-এও ফলকে early signal হিসেবে দেখতে এবং User Research-এর সঙ্গে মিলিয়ে বিশ্লেষণ করতে বলা হয়েছে।

আর interest কম হলে?

Low click rate মানেই idea বাতিল—এমন সিদ্ধান্তও তাড়াহুড়া হবে।

প্রথমে পরীক্ষা করুন:

Door কি User দেখতে পেয়েছে?

অস্বাভাবিক জায়গায় রাখা Button-এর কম click demand সম্পর্কে তেমন কিছু নাও বলতে পারে।

Label কি পরিষ্কার ছিল?

User Feature-এর value বুঝতে না পারলে ভালো idea-ও দুর্বল signal দিতে পারে।

সঠিক segment কি test-এ ছিল?

ভুল audience-এর ফল দিয়ে পুরো market সম্পর্কে সিদ্ধান্ত দেওয়া যায় না।

Feature কি একটি Button দিয়ে বোঝানো সম্ভব?

Complex workflow বা এমন Product যার value ব্যবহারের পর বোঝা যায়, সেগুলো Fake Door-এর জন্য দুর্বল candidate। Amplitude-ও discrete ও সহজে বোঝা যায় এমন Feature-এ পদ্ধতিটি বেশি কার্যকর বলে উল্লেখ করেছে।

সেটআপে স্পষ্ট সমস্যা না থাকলে low interest একটি গুরুত্বপূর্ণ evidence। তখন আরও Development করার বদলে hypothesis পুনর্বিবেচনা করাই যুক্তিসংগত।

সবচেয়ে বড় ভুল: Click-কে Demand-এর চূড়ান্ত প্রমাণ ভাবা

Fake Door Testing-এর শক্তি হলো এটি কথার বদলে কিছুটা আচরণ দেখতে দেয়। দুর্বলতাও ঠিক এখানেই—আচরণটি খুব ছোট।

একটি Button ক্লিক করতে User-এর প্রায় কোনো commitment লাগতে পারে না। কৌতূহল থেকেও click হতে পারে। অন্যদিকে Waitlist signup-এ একটু বেশি commitment আছে। Prototype ব্যবহার করতে আরও বেশি। টাকা দেওয়া, Product চালু রাখা বা Subscription renew করা তার চেয়েও শক্ত signal।

Amplitude-এর Painted Door guidance-এও সতর্ক করা হয়েছে যে curiosity থেকে signup বা interaction হতে পারে, যা প্রকৃত purchase intent-এর তুলনায় demand বেশি মনে করাতে পারে।

তাই evidence-কে স্তর ধরে দেখা ভালো:

Button click < Waitlist signup < Interview commitment < Prototype usage < MVP usage < Payment/renewal

এটি কোনো সার্বজনীন বৈজ্ঞানিক scoring formula নয়; Product Team-এর জন্য signal-এর শক্তি বোঝার একটি ব্যবহারিক কাঠামো।

Fake Door Test-এর নৈতিক সীমা কোথায়

“Fake” শব্দটি দেখে পদ্ধতিটিকে User ঠকানোর অনুমতি হিসেবে নেওয়া যাবে না।

একটি দায়িত্বশীল Fake Door Test-এর লক্ষ্য হলো অল্প সময়ের জন্য User intent মাপা এবং interaction-এর পর দ্রুত বাস্তব অবস্থা জানানো। AB Tasty এবং Amplitude—দুই উৎসই ভুলভাবে পরিচালিত Fake Door থেকে User trust ক্ষতিগ্রস্ত হওয়ার ঝুঁকির কথা উল্লেখ করে।

কয়েকটি সীমা রাখা জরুরি:

• unavailable Feature-কে নিশ্চিতভাবে available বলে প্রচার করবেন না;
• ক্লিকের পর দ্রুত disclosure দিন;
• User-এর মূল কাজ আটকে দেবেন না;
• একসঙ্গে অসংখ্য Fake Door দেখাবেন না;
• প্রয়োজন ছাড়া ব্যক্তিগত তথ্য সংগ্রহ করবেন না;
• Email চাইলে সেটি optional রাখুন;
• বাস্তবে সরবরাহ করা যাবে না এমন Product-এর জন্য payment নেওয়া এড়িয়ে চলুন;
• test এত দীর্ঘ করবেন না যে অকার্যকর Feature Product-এর স্থায়ী অংশ মনে হয়।

বিশেষ করে বিদ্যমান paying customer-এর workflow-তে Test চালালে বিশ্বাসের বিষয়টি click rate-এর চেয়েও গুরুত্বপূর্ণ হতে পারে।

কখন Fake Door Test না করাই ভালো

সব uncertainty Fake Door দিয়ে মাপা যায় না।

এটি দুর্বল পদ্ধতি হতে পারে যখন:

Feature-এর value ব্যবহারের আগে বোঝা কঠিন।

জটিল AI workflow, নতুন editing experience বা collaboration model একটি Button দেখে বিচার করা কঠিন।

মূল প্রশ্ন usability নিয়ে।

User Feature চায় কি না জানা আছে, কিন্তু ব্যবহার করতে পারবে কি না জানতে হলে Prototype বা usability test দরকার।

আইডিয়াটি ইতিমধ্যে শক্ত usage evidence দিয়ে সমর্থিত।

তখন আরেকটি Fake Door অতিরিক্ত friction তৈরি করতে পারে।

ভুল expectation তৈরির ক্ষতি বেশি।

বিশ্বাস-সংবেদনশীল workflow-তে অকার্যকর option দেখানো Brand বা User experience-এর জন্য প্রয়োজনের চেয়ে বেশি ঝুঁকিপূর্ণ হতে পারে।

Feature Development-এর আগে সবচেয়ে ব্যবহারিক সিদ্ধান্ত

Fake Door Test-এর মূল্য “কোড না লিখে নিশ্চিত উত্তর পাওয়া” নয়। এত শক্তিশালী নিশ্চয়তা এটি দিতে পারে না।

এর আসল কাজ হলো বড় Development commitment-এর আগে একটি সস্তা প্রশ্ন করা:

“User এই Feature সামনে পেলে বাস্তবে সেটি ব্যবহার করার চেষ্টা করছে কি?”

উত্তর ইতিবাচক হলে সঙ্গে সঙ্গে পুরো Feature বানানোর বদলে evidence আরও শক্ত করুন—ক্লিককারীদের সঙ্গে কথা বলুন, Prototype দেখান, তারপর প্রয়োজন হলে MVP তৈরি করুন। ফল দুর্বল হলে প্রথমে targeting, placement ও proposition পরীক্ষা করুন; সবকিছু ঠিক থাকার পরও interest না এলে Feature priority কমানোর যথেষ্ট কারণ পাওয়া যেতে পারে।

ভালোভাবে চালানো Fake Door Test Product roadmap থেকে অনুমান পুরোপুরি দূর করে না। তবে কোন ধারণার পেছনে Engineering সময় দেওয়া উচিত এবং কোন ধারণা আরও যাচাই চায়—এই সিদ্ধান্তটি অনেক বেশি তথ্যভিত্তিক করে।

শেষ কথা

Fake Door Test-এর সবচেয়ে বড় ব্যবহারিক মূল্য হলো—Feature বানানোর আগে অনুমানকে আচরণ দিয়ে যাচাই করা। তবে একটি click-কে চূড়ান্ত demand ধরে নেওয়া ঠিক নয়। ভালো signal পাওয়া গেলে Interview, Prototype বা MVP দিয়ে সেই আগ্রহ আরও গভীরভাবে যাচাই করতে হবে। আর interest দুর্বল হলে আগে audience, placement ও message ঠিক ছিল কি না তা পরীক্ষা করা উচিত।

নতুন Feature নিয়ে Engineering সময় ও বাজেট খরচ করার আগে এই ছোট পরীক্ষা Product Team-কে একটি গুরুত্বপূর্ণ সিদ্ধান্ত নিতে সাহায্য করতে পারে: এখনই বানানো উচিত, নাকি আগে আরও evidence সংগ্রহ করা দরকার।

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

Fake Door Test চালাতে কি বিশেষ কোনো সফটওয়্যার প্রয়োজন?

অবশ্যই নয়। সাধারণ Button বা Landing page-ভিত্তিক পরীক্ষায় existing Product analytics, event tracking এবং সীমিত Development দিয়েও কাজ করা সম্ভব। জটিল segmentation বা controlled experiment প্রয়োজন হলে experimentation বা feature-management tooling কাজে লাগতে পারে।

Fake Door Test কতদিন চালানো উচিত?

সবার জন্য নির্দিষ্ট সময় নেই। পর্যাপ্ত relevant User exposure পাওয়া, traffic pattern এবং আগে নির্ধারিত decision criteria-এর ওপর সময় নির্ভর করবে। অল্প traffic দেখে দ্রুত সিদ্ধান্ত নেওয়া যেমন দুর্বল, তেমনি User-দের দীর্ঘ সময় অকার্যকর Door দেখিয়ে রাখাও ঠিক নয়।

Fake Door Test কি Market Validation সম্পূর্ণ করে?

না। এটি Market Validation-এর একটি প্রাথমিক evidence source। এটি interest বা intent দেখাতে পারে, কিন্তু Product ব্যবহার, satisfaction, retention এবং willingness to pay আলাদাভাবে যাচাই করতে হয়।