শূন্য থেকে লঞ্চ: Pathao Points যেভাবে তৈরি হলো

এই লেখাটি প্রথম ২০১৯ সালের ২৮ অক্টোবর Future Startup-এ প্রকাশিত হয়েছিল

এই মাসে আমরা Pathao Points লঞ্চ করেছি — একটা ইউনিক রিওয়ার্ডস প্রোগ্রাম, যেখানে আমাদের কাস্টমাররা রাইড বা ফুড ডেলিভারির জন্য যতবার Pathao ব্যবহার করবেন, ততবারই পয়েন্ট পাবেন। পথে পথে এই পয়েন্টগুলো আমাদের মেম্বারদের জন্য এক্সক্লুসিভ আর দারুণ সব সুবিধা আনলক করবে।

এই লঞ্চের পর আমাদের কাছে জানতে চাওয়া হয়েছে

এমন একটা প্রোডাক্ট (Pathao Points) লঞ্চ করার পেছনে আপনাদের যুক্তি কী? এটা কীভাবে কাজ করে? এর পেছনে কী রিসার্চ হয়েছে? কত সময় লেগেছে? আমরা কি দীর্ঘমেয়াদের কথা ভেবে ডিজাইন করেছি? আমরা কোন মেট্রিকগুলো দেখি?

এই প্রশ্নগুলো শুধু Pathao Points-এর জন্যই প্রাসঙ্গিক নয়, যেকোনো প্রোডাক্ট ডেভেলপমেন্টের প্রেক্ষাপটেই প্রাসঙ্গিক — সেটা Pathao Points, Rides, Food হোক — কিংবা অন্য যেকোনো টেক প্রোডাক্ট।

৩ পর্বের এই সিরিজে আমি Pathao Points-কে উদাহরণ হিসেবে নিয়ে এই প্রশ্নগুলোর উত্তর দেওয়ার পরিকল্পনা করেছি, তবে আশা করি খুঁটিনাটিগুলো বাংলাদেশে আর তার বাইরে টেকনোলজি প্রোডাক্ট ডেভেলপ করছেন এমন যে কারও কাজে লাগবে।

শুরু করা যাক ‘কেন’ দিয়ে

Pathao Points বানানোরই বা দরকার কী ছিল?

দেশে গড়ে ওঠা একটা স্টার্টআপ হিসেবে, আমাদের এই যাত্রার বড় একটা অংশ জুড়ে আছে আমাদের কমিউনিটি।

আমাদের বেছে নেওয়ার জন্য এই কমিউনিটিকে স্বীকৃতি আর পুরস্কার দিতে আমরা সবসময়ই চেয়েছি। এই প্রোগ্রামের মধ্য দিয়ে সেই পথে বড় একটা পদক্ষেপ নিতে পেরে আমরা এক্সাইটেড।

কাস্টমার রিটেনশন আমাদের ফোকাসের বড় একটা জায়গা। আমরা চাই, ইউজাররা ধারাবাহিকভাবে আমাদেরকেই তাঁদের পছন্দের প্ল্যাটফর্ম হিসেবে বেছে নিন, আর এর জন্য কাজ করতে আমরা আগ্রহী।

একজন বিদ্যমান ইউজারকে ধরে রাখার চেয়ে নতুন ইউজার আনা অনেক বেশি ব্যয়বহুল।

তাই যে কাস্টমাররা আমাদের সঙ্গে আছেন, তাঁদের জন্য কিছু বানাতেই চেষ্টা ঢালাটা যুক্তিসঙ্গত। Pathao Points ঠিক সেটাই — আমাদের ইউজারদের স্বীকৃতি আর পুরস্কার দেওয়ার একটা প্রোগ্রাম।

আচ্ছা। এটা কাজ করে কীভাবে?

ইউজাররা যে পয়েন্ট জমান, তা দিয়ে তাঁরা নানা রকম রিওয়ার্ড আর ডিসকাউন্টের সুযোগ পান, যেগুলো এমনভাবে ডিজাইন করা যাতে সত্যিই তাঁদের কাছে গুরুত্বপূর্ণ হয়।

মেম্বারশিপ লেভেল চারটা: Bronze, Silver, Gold, Platinum, আর ইউজাররা কোনো খরচ ছাড়াই অটোমেটিক্যালি এনরোল হয়ে যান।

প্রোগ্রামে ঢোকার পর ইউজাররা Pathao প্ল্যাটফর্মে খরচ করা প্রতি টাকায় এক পয়েন্ট করে পেতে শুরু করবেন। ২০০ পয়েন্ট হলে একজন ইউজার Bronze থেকে Silver-এ উঠবেন। ১,০০০ পয়েন্টে প্রমোশন পেয়ে যাবেন Gold টিয়ারে। আর ৭,০০০ পয়েন্টে পৌঁছে যাবেন সবচেয়ে উঁচু টিয়ার, Platinum-এ।

এই প্রজেক্টটা যেহেতু রিওয়ার্ড আর কাস্টমার রিলেশনশিপ নিয়ে, তাই আমাদের মনে হয়েছিল আস্থা আর নির্ভরযোগ্যতা খুব গুরুত্বপূর্ণ। এই প্রজেক্টের ইন্টারনাল নাম ছিল ‘Sancus’ — আস্থা আর শপথের গ্রিক দেবতার নামে।

দ্রুত বানানোর ‘সিক্রেট সস’ কী ছিল?

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

ওয়েব-ভিউয়ের ওপর বাজি

চিত্র: MVP লঞ্চের আগে আমরা যেসব এক্সপ্লোরেশন আর রিফাইনমেন্ট করেছি।

রিলিজের পর আমরা ধরে নিয়েছিলাম, মার্কেটের ফিডব্যাকের ভিত্তিতে এই প্রোডাক্টের প্রথম ভার্সন অনেকবার ইটারেশনের মধ্য দিয়ে যাবে।

দ্রুত বদল আনা আর সহজে আপডেট পুশ করার জন্য — নেটিভ Android/iOS-এর বদলে ওয়েবে ফ্রন্টএন্ড বানানোটাই যুক্তিসঙ্গত মনে হয়েছিল।

একদিকে, Android/iOS প্ল্যাটফর্মে ফ্রন্টএন্ড বদলাতে হলে পুরো আপডেট লাগে, আর সেটা নির্ভর করে ইউজার ওই আপডেট নেবেন কি না, তার ওপর।

অন্যদিকে, ওয়েব-ভিউ অ্যাপ্রোচে প্রতিবার আপডেট করা UI লোড হয়।

কিন্তু ওয়েব-ভিউভিত্তিক অ্যাপ্রোচ নিয়ে কিছু দুশ্চিন্তাও ছিল।

অ্যাপ এক্সপেরিয়েন্সের বড় কোনো অংশে আমরা আগে কখনো ওয়েব-ভিউ ব্যবহার করিনি। স্বাভাবিকভাবেই, এটা ছিল অচেনা জায়গা।

এক্সপেরিয়েন্সে কি কোনো ছাড় দিতে হবে? ল্যাগ হবে? অ্যাপের বাকি অংশের তুলনায় কি এটা বেমানান লাগতে পারে? ফ্রন্টএন্ড কি লোড সামলাতে পারবে?

আমরা এক্সপেরিমেন্ট করার সিদ্ধান্ত নিলাম, আর একটা POC (প্রুফ-অব-কনসেপ্ট) বানালাম। আমাদের ওয়েব ফ্রন্টএন্ড টিম কয়েকটা HTML/CSS পেজ বানাল। আমরা সেগুলো অ্যাপের সঙ্গে জুড়ে পারফরম্যান্স টেস্ট করলাম। ফলাফল আমাদের আশার চেয়েও অনেক ভালো হলো।

নিখুঁত ছিল না, কিন্তু ঘষেমেজে আর ইটারেট করে দারুণ কিছু বানানো যেত। কয়েকটা ইউজেবিলিটি ইস্যু ছিল, কিছু ডিজাইনের বিবেচনা ছিল। বলতে পারেন, আকাটা হীরা।

কয়েকবার ইটারেশনের পর পারফরম্যান্স নিয়ে আমরা খুশি ছিলাম। কোনো ল্যাগ নেই। বড় কোনো ইউজেবিলিটি ইস্যু নেই। কোনো বাগ নেই। আমরা ওয়েব-ভিউ সমাধান নিয়েই এগোনোর সিদ্ধান্ত নিলাম।

২. Lego, আমাদের UI লাইব্রেরি

Lego-র কভার

এ বছরের শুরুতে আমরা আমাদের ডিজাইন ল্যাঙ্গুয়েজ আর গাইডলাইন স্ট্যান্ডার্ডাইজ করতে সময় দিয়েছিলাম। নিজেদের প্রয়োজন মেটায় এমন প্লাগেবল কম্পোনেন্ট দিয়ে আমরা নিজস্ব একটা UI লাইব্রেরি বানিয়েছিলাম, নাম Lego।

এই লাইব্রেরিই আমাদের সোর্স অব ট্রুথ। নতুন প্রজেক্ট শুরু করার জন্য এটা বয়লারপ্লেটের কাজ করে। আরও গুরুত্বপূর্ণ হলো, Lego আমাদের অ্যাপ, ওয়েবসাইট আর অন্যান্য টাচপয়েন্টজুড়ে সামঞ্জস্য নিশ্চিত করে।

সংক্ষেপে, যেকোনো UI-তে কাজ করার সময় Lego সময় বাঁচায়, আর বিদ্যুৎগতিতে নতুন ইউজার এক্সপেরিয়েন্স বানাতে সাহায্য করে।

৩. মাইক্রোসার্ভিসভিত্তিক আর্কিটেকচার

আগে আমাদের Payments সার্ভিসের মতো একই ধরনের মজবুত সিস্টেম বানানোর প্যাটার্ন আর শিক্ষা কাজে লাগিয়ে, আমাদের ইঞ্জিনিয়ারিং টিম মাইক্রোসার্ভিসভিত্তিক আর্কিটেকচার বেছে নিল। হাই-লেভেলে, মূল সার্ভিস হবে চারটা।

POCKETS – পয়েন্টসংক্রান্ত সবকিছু সামলাবে।
SQUARE – ডিলসংক্রান্ত সবকিছুর দায়িত্বে।
NIGHTWING– ডিল ম্যানেজ করার অ্যাডমিন টুল।
QUICKSILVER- ওয়েব-ভিউ রেন্ডার করার দায়িত্বে।

এগুলোকে সাপোর্ট দিতে আরও কয়েকটা মাইক্রোসার্ভিস লাগবে, তবে মোটের ওপর এই চারটাই হবে সেই স্তম্ভ, যার ওপর আমরা এই সিস্টেম দাঁড় করাব।

৪. এক্সপেরিমেন্ট আর ইমপ্যাক্ট মাপার জন্য ডিজাইন

প্রথাগতভাবে, প্রোডাক্ট রিলিজের ইমপ্যাক্ট মাপার কথা ভাবা হয় সবার শেষে। এতে কারোরই লাভ হয় না। এখন আমরা কোডের এক লাইন লেখার আগেই এর পরিকল্পনা করি।

একটা ফিচার বা ভেরিয়েবল কতটা জরুরি, তা নির্ভরযোগ্যভাবে জানা কঠিন, যদি না আমরা সেটা কন্ট্রোল আর ট্রিটমেন্ট — দুই পরিবেশেই ডিপ্লয় করে এর প্রভাব মাপতে পারি।

অবশ্যই, ইউজারদের ইন্টারভিউ নেওয়ার মতো কোয়ালিটেটিভ উপায়ও ব্যবহার করা যায় — কিন্তু তাতে সমস্যা আছে। Pathao যে স্কেলে চলে, সেখানে FGD আর ইন্টারভিউ খুব কমই প্রতিনিধিত্বমূলক হয়। বিশেষ করে এমন প্রোডাক্টের ক্ষেত্রে, যেটা পুরো প্ল্যাটফর্মজুড়ে চলে। তাই কোয়ান্টিটেটিভ পদ্ধতি, A/B টেস্টিংই আমাদের পথ।

অবশ্যই, বলা যত সহজ, করা তত সহজ নয়।

ঠিকঠাক একটা এক্সপেরিমেন্ট আর A/B টেস্ট চালাতে ডেভেলপমেন্ট, সেটআপ আর জানাশোনা লাগে। অভিজ্ঞতা ছাড়া এমন দক্ষতা খুব কমই পাওয়া যায়।

Sancus (ইন্টারনাল নাম) নিয়ে আমাদের বেশিরভাগ প্রশ্নে — যেসব জিনিস আমরা টেস্ট আর ইটারেট করতে চাই — A/B টেস্টিং মেকানিজম বিল্ট-ইন আছে।

তার মানে, আমরা কন্ট্রোল-ট্রিটমেন্ট গ্রুপ রাখতে পারি, নির্দিষ্ট ইউজার কোহর্টে নির্দিষ্ট ফিচার রোলআউট করতে পারি, আরও অনেক কিছু।

এরপর আমরা দুই গ্রুপের ডেটা মনিটর করি, ইনসাইট বের করতে ডেটা অ্যানালাইজ করি, আর উপযুক্ত পদক্ষেপ নিই।

পিটার ড্রাকার ঠিকই বলেছিলেন,

“যা মাপা হয়, তা-ই ম্যানেজ করা যায়”

৫. প্রজেক্ট ম্যানেজমেন্ট, কাজের পথে বাধা না হয়ে

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

আমাদের Capstone প্রজেক্ট ম্যানেজমেন্ট ট্র্যাকার – প্রোডাক্ট আর ইঞ্জিনিয়ারিং লিডরা এটা মেইনটেইন করেন; এতে আমাদের অগ্রগতি আর অগ্রাধিকারের একটা বার্ডস-আই ভিউ পাওয়া যায়।
স্ট্যান্ডআপ আর সামনাসামনি মিটিং – ৬/৭ জনের কোর টিম নিয়ে মোটামুটি সপ্তাহে দুবার স্ট্যান্ডআপ হতো। সাধারণত সোমবার আর বৃহস্পতিবার। এই ছন্দে আমরা আটকে থাকা ইস্যুগুলো ছাড়াতে আর অগ্রগতির খোঁজ রাখতে পারতাম — আবার এ ধরনের মিটিংয়ে সময়ও যেত সবচেয়ে কম।
আমরা দেখেছি, সামনাসামনি যোগাযোগ অপরিহার্য। কিন্তু আবার, যারা বানাচ্ছে তাদের আমরা মিটিংয়ে ডুবিয়ে রাখতে চাই না। অন্যদিকে, ইমেইল আর টেক্সট মেসেজ কখনো কখনো সমন্বয়ের ধীর উপায়। আমাদের একটা ভারসাম্য খুঁজে বের করতে হতো।
রেট্রোস্পেক্টিভের সময় আমরা ইচ্ছে করেই নেতিবাচক দিকগুলোতে বেশি সময় দিই। কোনো কিছুই, কোনো কিছুই আলোচনার বাইরে নয়, কিন্তু সবকিছু থেকেই একটা পদক্ষেপ বের হতে হবে।
যা গুরুত্বপূর্ণ, তা ডকুমেন্ট করুন:

একদম শুরু থেকেই টেক, মার্কেটপ্লেস, মার্কেটিং, পার্টনারশিপস — এমন বিভিন্ন টিমের সঙ্গে যত মিটিং করছিলাম, সবগুলোর মিনিটস রাখতে শুরু করি। প্রতিটা মিটিং শেষে একটা রিক্যাপ আর পরের পদক্ষেপগুলো পাঠিয়ে দিতাম। এই শৃঙ্খলা পুরো সময় টেকেনি, তবে আমাদের যাত্রা শুরু করিয়ে দেওয়ার মতো যথেষ্ট সময় ধরে ছিল।

এটা যাঁদের জন্য সম্ভব হয়েছে, সেই টিমের একটা ছবি…

বলার অপেক্ষা রাখে না, অনেকেই অবদান রেখেছেন কিন্তু ফ্রেমে নেই, তাঁদের প্রতি আমরা কৃতজ্ঞ। তাঁদের মধ্যে এই প্রোডাক্টের শুরুর দিকে অবদানের জন্য জিতু ভাইয়ের কথা বলব।