Lúa hóa kiến thức
Hãy thu thập dấu hiệu của sự cam kết trước khi làm sản phẩm
🕔 6 thg 11, 2024
🧑🎓 Ông Giáo, Khánh Đàm
Trong bài viết Tại sao nên nói về cuộc sống của người dùng thay vì ý tưởng của bản thân? và Những câu hỏi quan trọng, chúng mình đã đề cập đến việc phỏng vấn người dùng trước khi quyết định xây dựng sản phẩm. Tuy nhiên, trên thực tế, quá trình research không nên dừng lại ở đây, mà thay vào đó là diễn ra trong suốt quá trình xây dựng sản phẩm, nhằm xác định sự cam kết của người dùng.
Trong bài này, mình sẽ kể về hai tính năng: một thành công, một thất bại. Qua đó, chúng mình sẽ thấy rõ tầm quan trọng của việc xác định sự cam kết của người dùng với sản phẩm.
Chúng mình là thuộc bộ phận sản phẩm kỹ thuật số tại một công ty giáo dục. Sản phẩm mà team mình phụ trách là một nền tảng học trực tuyến (e-Learning). Nhiệm vụ của chúng mình là phối hợp với các phòng ban khác trong công ty để tích hợp việc học trực tuyến vào quy trình giảng dạy cho các em học sinh. Nói một cách đơn giản, một phần công việc của chúng mình là dưới mô hình outsource nội bộ.
💡 Outsource nội bộ là khi một công ty sử dụng một bộ phận, đội ngũ, hoặc cá nhân trong chính tổ chức của mình để thực hiện các công việc hoặc dự án thay vì thuê bên ngoài. Đây là một hình thức giao việc giữa các phòng ban, bộ phận, hoặc chi nhánh của công ty mà không cần phải tìm kiếm nguồn lực bên ngoài. Với trường hợp của chúng mình, nhân sự của các phòng ban khác là một trong các người dùng cuối.
Tính năng thất bại
💡 Trong sản phẩm của chúng mình có một nhóm người dùng rất quan trọng là đội ngũ R&D (Research & Development). Đội ngũ R&D có nhiệm vụ nghiên cứu, phát triển và thiết kế nội dung học tập trên sản phẩm e-Learning. Ban đầu, sản phẩm e-Learning của mình chỉ có một định dạng làm bài tập duy nhất, đó là làm trắc nghiệm.
Sau khi triển khai được một thời gian, mình có một cuộc trò chuyện vô tình với trưởng nhóm R&D và nhận được một gợi ý về một tính năng mới.
Mình: “Dạo này team R&D nhà anh dùng sản phẩm ổn không ạ?”
Trưởng nhóm R&D: “Cũng tạm ổn, mất thời gian đầu để training thôi.”
Mình: “Anh thấy cần thêm gì để thiết kế bài giảng hiệu quả hơn không ạ?”
Trưởng nhóm R&D: “Chắc là làm sao cho các câu hỏi đa dạng hơn em ạ, giờ thấy câu nào cũng như câu nào.”
Mình: “Vậy em làm thêm mấy định dạng khác cho phong phú nhé ạ?”
Trưởng nhóm R&D: “Ô kê em cứ làm đi, bao giờ xong thì bảo anh. Bọn anh chắc là cũng sắp làm lại giáo trình.”
Chúng mình rút ra kết luận là: Cần đa dạng hóa định dạng làm bài tập do sắp tới team R&D sẽ xây dựng lại giáo trình.
Và thế là mình và team hí hửng, bắt đầu những buổi grooming đầu tiên cho tính năng sắp tới.
💡 Buổi họp grooming tính năng sản phẩm (Product backlog grooming) là một cuộc họp trong quy trình phát triển Agile, nơi team Product và các bên liên quan cùng nhau xem xét, phân tích, và điều chỉnh các mục trong backlog (danh sách công việc cần làm). Mục tiêu là làm rõ yêu cầu, ưu tiên các tính năng, và đảm bảo rằng các mục này sẵn sàng để được triển khai trong các sprint tiếp theo.
Chúng mình dần hoàn thành ý tưởng và cho ra những bản wireframe đầu tiên cho giải pháp, đó là thêm định dạng Điền vào chỗ trống (Fill-in-the-blank) và Ghép đáp án (Matching). Giờ đã đến lúc gọi team R&D vào để cùng review. Mọi thứ diễn ra có vẻ khá suôn sẻ với cái gật đầu chớp nhoáng từ team R&D.
Hai sprint sau, tính năng đã ra lò. Chỉ có điều là…
Chỉ có điều là từ đó đến nay, chưa bao giờ các em học sinh được sử dụng định dạng làm bài này. Lí do là bởi vì team R&D thực chất không có ý định xây dựng lại giáo trình mới cho đến cuối năm. Và đến cuối năm thì team R&D lại thay đổi định hướng phục vụ nhóm học sinh khác, dẫn đến họ cũng không còn cần tính năng này nữa.
Nói theo ngôn ngữ phát triển sản phẩm thì, chúng mình đã lãng phí hai sprint chỉ để phát triển một tính năng không được ưu tiên và không được sử dụng. Còn nói theo ngôn ngữ tài chính thì đó là một tháng lương của 5 thành viên team mình.
Cuộc hội thoại của mình với trưởng nhóm R&D thực chất không hề có một bằng chứng cụ thể nào cho thấy họ thực sự sẽ dùng sản phẩm cả. Ví dụ như câu nói: “Bao giờ xong thì bảo anh” là một câu nói cho thấy rằng tính năng của mình có cũng được mà không có cũng được.
Tính năng thành công
Vẫn với sản phẩm e-Learning, nhưng lần này chúng mình phục vụ một stakeholder khác, đó là đội ngũ Vận Hành Lớp Học.
💡Đội ngũ Vận Hành Lớp Học có có nhiệm vụ đảm bảo rằng học sinh và phụ huynh có trải nghiệm học tập tích cực và hiệu quả. Trong sản phẩm của chúng mình, mỗi bạn vận hành sẽ quản lý tài khoản và giao bài tập cho các em học sinh trong lớp mà mình phụ trách.
Trước đây, mỗi khi có một học sinh mới, các bạn vận hành sẽ phải tạo tài khoản và cấp quyền sử dụng sản phẩm cho em học sinh đó. Mỗi lần thực hiện hành động này, các bạn sẽ phải trải qua đâu đó 5 màn hình, phải tra cứu các thông tin như mã học sinh, môn học, hình thức học,… và nhập thủ công. Tổng cộng mất khoảng 4-5 phút cho mỗi em học sinh.
Hãy tưởng tượng mỗi bạn vận hành phụ trách khoảng 5 lớp, mỗi lớp khoảng 15 học sinh, thì gần như cả ngày chỉ có ngồi tạo tài khoản và phân quyền. Ngoài ra, điều này khiến cho các bạn vận hành mới nhận việc rất khó làm quen.
Cả team mình đã phải dừng lại mọi công việc để nghĩ giải pháp cho vấn đề này.
Tuy nhiên, lần này do đã có kinh nghiệm hơn lần trước, mình đã chủ động hơn trong việc tìm kiếm bằng chứng rằng team Vận Hành sẽ sử dụng tính năng của mình. Cụ thể, trước và trong quá trình làm tính năng, mình đặt những câu hỏi như:
Mình: “Con số mà cả team em và team Vận Hành hướng đến là gì ạ?”
Trưởng nhóm Vận Hành: “Mình sẽ làm sao cho tỷ lệ Adoption ít nhất là 80% nhé. Nếu quá 2 tuần triển khai mà không đạt được số này thì mình phải đổi chiến lược ngay.”
Mình: “Tính năng này lúc được release sẽ ảnh hưởng đến cả quá trình vận hành lớp của các nhân sự team chị đấy ạ, COO liệu có đồng ý không ạ?”
Trưởng nhóm Vận Hành: “Em yên tâm, chiều mai họp Quản Lý chị sẽ đề cập đến việc này.”
Mình: “Tính năng này vẫn sẽ yêu cầu một số thao tác nhất định, làm sao để chị đảm bảo các bạn nhân sự mới nắm được hướng dẫn sử dụng ạ?”
Trưởng nhóm Vận Hành: “Chị có cho nhân sự team chị viết lại Meeting Minute buổi hôm nay rồi, ngày kia bạn ý sẽ viết thành guideline và gửi lại cho em review.”
…
Không những thế, gần như mỗi ngày trong 2 sprint phát triển tính năng, ngày nào mình cũng nhận được những tin nhắn như kiểu:
“Bao giờ ra được bước tiếp theo hả em ơi?”
“Sắp release chưa để chị báo các lớp chạy thử?”
“Làm nhanh lên nhé, chị set lịch training cho toàn bộ hệ thống vào cuối tuần này rồi đấy”
Trưởng nhóm Vận Hành đã chủ động báo cáo với cấp trên về tính năng này, tham gia các buổi grooming thiết kế tính năng, và song song đó cũng chuẩn bị cho việc tích hợp tính năng này vào luồng làm việc của team. Đây chính là tín hiệu cho thấy họ thực sự cần tính năng này.
Và cuối cùng ngày đó cũng đến, tính năng tự động hóa quy trình cấp tài khoản cho học viên, sau bao nhiêu buổi thử nghiệm, đã được release chính thức. Không chỉ thể, chỉ trong vòng chưa đầy một tuần, tính năng này đã được triển khai trên toàn bộ các cơ sở của công ty.
Điểm khác nhau giữa 2 tính năng là gì?
Thực tế, điểm khác nhau trong 2 tính năng này nằm ở cách chúng mình đã thu thập dữ liệu về nhu cầu cấp thiết của hai team.
Với team R&D, chúng mình đã không chủ động tìm kiếm tín hiệu của sự cần thiết, do đó không biết được họ có thực sự cần tính năng này hay không. Chúng mình không biết họ cần đến mức độ nào, bao giờ họ sẽ dùng tính năng, hay họ sẽ dùng để làm gì. Họ cũng không hề cho thấy họ cần tính năng này, bằng chứng là họ chỉ nhanh chóng duyệt giải pháp chứ cũng không quá bận tâm. Điều này dẫn đến việc sai sót trong việc ưu tiên làm tính năng và làm ra tính năng không thực sự cần thiết vào thời điểm đó.
Nghe thì có vẻ ngớ ngẩn, nhưng trên thực tế, có đến 35% startup thất bại do làm ra sản phẩm mà người dùng không cần, và 10% startup thất bại do làm đúng sản phẩm nhưng sai thời điểm (nguồn: tại đây).
Còn với team Vận hành, do chúng mình đã có những câu hỏi rất cụ thể để xác nhận nhu cầu nên chúng mình đã thấy được họ rất cần tính năng này, thậm chí cần rất gấp. Họ bỏ thời gian ra để xắn tay áo lên làm cùng chúng mình, họ chấp nhận rủi ro về mặt uy tín khi giới thiệu tính năng này đến cấp trên, họ chủ động thử nghiệm trên người dùng cuối, hay lên lịch training khi tính năng còn chưa sẵn sàng.
Nói cách khác, nhờ chiếc lược kiểm tra nhu cầu, chúng mình thấy rõ được sự cam kết của team Vận Hành, còn với team R&D thì mù mờ và không hề chắc chắn.
💡 Cam kết (Commitment) của người dùng được định nghĩa là một dấu hiệu cho thấy họ thực sự quan tâm và có khả năng sử dụng sản phẩm hoặc dịch vụ mà chúng mình đang phát triển. Điều này được thể hiện qua cam kết về Thời gian, về Uy tín và về Tài chính thay vì lời nói suông.
Chúng mình sẽ lấy ví dụ cụ thể để giải thích 3 loại cam kết này.
Tháng 4 năm 2021, khóa UXF đầu tiên đã ra đời. Vào khoảng đầu năm, Ông Giáo bắt đầu có ý tưởng về việc đi dạy. Theo logic thông thường thì có lẽ sẽ xây dựng giáo trình trước và bắt đầu mở đăng ký khóa học. NHƯNG, Ông Giáo đã không làm thế. Ông Giáo đã kiểm tra ý tưởng của bản thân bằng cách mở đăng ký trước để xem có dấu hiệu của sự cam kết đến từ học viên không. Cụ thể, Ông Giáo đã viết một bài viết giải thích lí do tại sao ổng mở lớp, kèm link đăng ký. Mọi người có thể đào lại bài viết mở đăng ký khóa học tại đây nhé!
Trong chưa đầy 2 tuần, lớp đầu tiên đã đủ số lượng đăng ký. Điều đặc biệt ở trong quá trình đăng ký tham gia lớp là: chưa có thời gian cụ thể khi nào lớp sẽ bắt đầu, và yêu cầu thanh toán trước một phần học phí. Còn đặc biệt hơn là nếu đọc phần bình luận của bài viết này sẽ thấy khá nhiều comment của mọi người tag rủ người quen đi học.
Sau đó thì Ông giáo mới tiếp tục hoàn thiện giáo trình và các công tác chuẩn bị khác cho khóa học đầu tiên.
Qua ví dụ này, chúng mình có thể thấy sự cam kết của học viên UXF qua:
Thời gian: Mọi người sẵn sàng chờ đến ngày bắt đầu đi học, thậm chí không cần biết phải chờ bao lâu
Uy tín: Mọi người sẵn sàng rủ bạn bè mình đăng ký học dù chưa biết khóa học sẽ ra sao
Tài chính: Mọi người sẵn sàng xuống tiền đóng trước học phí đễ giữ chỗ
Đây chính là chiến lược “Pre-selling” (“Bán sản phẩm trước - Phát triển sản phẩm sau”). Ưu điểm mà chiến lược này đem lại là giúp:
Kiểm tra tính hữu dụng (Usefulness) của ý tưởng mà không tốn quá nhiều chi phí & thời gian
Sinh ra dòng tiền, giúp doanh nghiệp có nguồn lực để đầu tư phát triển sản phẩm
Giảm thiểu rủi ro đầu tư
Trong trường hợp đẹp nhất thì người dùng sẽ chủ động thể hiện sự cam kết, như với ví dụ của team Vận Hành ở trên, nhưng đa số trường hợp thì sẽ không như vậy.
Thế nên việc chúng mình cần làm chủ động tìm kiếm sự cam kết của người dùng. Sẽ không có một công thức phù hợp với mọi trường hợp. Chúng mình cần linh hoạt với từng loại sản phẩm, dịch vụ mình đang xây dựng cũng như với từng nhóm người dùng. Miễn sao chúng mình đề cập được ít nhất một trong ba yếu tố: Thời gian, Uy tín và Tài chính là được. Chúng mình sẽ lấy các giai đoạn của một startup để làm ví dụ nhé:
Giai đoạn ý tưởng (Ideate):
Ở giai đoạn này, chúng mình có thể dùng hai cách để kiểm tra sự cam kết của người dùng:
Bán ý tưởng hoặc Pre-order: Cách này giúp chúng mình xác định được yếu tố: Thời gian và Tài chính. Việc người dùng sẵn sàng bỏ tiền ra và chờ đợi sản phẩm của chúng mình chính là tín hiệu tốt.
Ví dụ chính là việc bán khóa học của Ông Giáo bên trên.
Thu thập thông tin người dùng qua Wishlist: Cách này giúp chúng mình xác định được yếu tố: Thời gian và Uy tín. Ngoài việc sẵn sàng chờ đợi sản phẩm, việc để lại tên, Email hay số điện thoại - những thông tin cá nhân cũng là một tín hiệu tốt. Cách này sẽ kém hiệu quả hơn một chút, nhưng cũng rất đáng để thử.
Ví dụ như Dora - một sản phẩm thiết kế UI bằng trí tuệ nhân tạo, cách đây vài năm đã được cộng đồng thiết kế truyền tai nhau tham gia wishlist.
Giai đoạn phát triển (Development):
Ở giai đoạn này, chúng mình vẫn cần kiểm tra sự cam kết của người dùng, cụ thể bằng cách:
Bán Prototype (bản dùng thử): Cách này ít nhất sẽ giúp chúng mình xác nhận được yếu tố: Tài chính khi mà người dùng sẵn sàng bỏ tiền ra mua một sản phẩm chưa hoàn chỉnh. Ngoài ra, nếu theo dõi kỹ, chúng mình cũng có thể xác nhận được yếu tố Uy tín nếu sản phẩm của chúng mình được nhiều phản hồi tốt hay được giới thiệu rộng rãi.
Ví dụ là các sản phẩm trên những nền tảng huy động vốn cộng đồng (crowdfunding platforms) như Kickstarter, Indiegogo, hay Product Hunt.
💡 Prototype (bản dùng thử) là một phiên bản thử nghiệm hoặc mẫu ban đầu của sản phẩm với chức năng hạn chế, giúp kiểm tra và minh họa các tính năng, giao diện hoặc chức năng trước khi phát triển hoàn chỉnh.
Giai đoạn ra mắt (Launch):
Ở giai đoạn này, chúng mình gần như khó có thể thay đổi nhiều về sản phẩm nữa rồi, tuy nhiên chúng mình vẫn cần theo dõi các tín hiệu để biết được: Liệu sản phẩm của mình có bán được ổn định không?
Lí do là bởi, có nhiều sản phẩm chỉ phù hợp trong một khoảng thời gian nhất định, nhưng chưa chắc có thể bền vững về lâu về dài.
Ví dụ như iPod của Apple, nó có thể phù hợp trong giai đoạn đầu những năm 2000, nhưng khi các dòng điện thoại thông minh khác nói chung, hay iPhone nói riêng, được ra mắt với sự tích hợp của tính năng nghe nhạc, nhu cầu sử hữu một thiết bị chỉ để phục vụ nhu cầu nghe nhạc đã giảm đi đáng kể.
Do đó, việc liên tục theo dõi các chỉ số sản phẩm là cực kỳ quan trọng, có thể là:
Time Spent (Thời gian sử dụng): Người dùng có sử dụng sản phẩm nhiều không?
Monthly Sales (Doanh thu hàng tháng): Sản phẩm của mình có bán được không? Và có bán được ổn định không?
NPS (Net Promoter Score - Điểm số người giới thiệu ròng): Người dùng có sẵn sàng giới thiệu sản phẩm cho người dùng khác không?
Ví dụ chính là các khóa học của UX Foundation, có các yếu tố sau giúp chúng mình xác định được commitment của các bạn học viên:
Mọi người sẵn sàng chờ vài tháng để đi học, và trong các buổi học mọi người đều tham gia đầy đủ dù buổi học có kéo dài đến 12 giờ đêm ⇒ Đây là cam kết về mặt Thời gian.
Mọi người sẵn sàng đóng trước một phần học phí để giữ chỗ. Ngoài ra, lớp của chúng mình luôn kín trước một vài tháng, bất kể các giai đoạn thăng trầm của thị trường thiết kế ⇒ Đây là cam kết về mặt Tài chính.
Mọi người sẵn sàng giới thiệu đồng nghiệp, bạn bè hay người thân đi học sau khi đã tốt nghiệp (Có một fact là đa số học viên của chúng mình đều là do học viên cũ giới thiệu) ⇒ Đây là cam kết về mặt Uy tín.
Tương tự, với mỗi sản phẩm hay dịch vụ, chúng mình sẽ có những chỉ số đo lường phù hợp khác nhau.
Qua các giai đoạn ở trên, chúng mình có thể thấy một điểm chung, và có lẽ cũng là điểm quan trọng nhất, đó là: Luôn luôn phải bán được sản phẩm.
Tuy nhiên
Tuy nhiên, chúng mình cũng cần chọn đúng thời điểm để đưa ra yêu cầu. Nếu quá sớm, khả năng cao là người dùng sẽ chưa đủ tin tưởng để chấp nhận chúng mình. Tuy nhiên, nếu quá muộn, thì chúng mình có rủi ro đã đầu tư quá nhiều thời gian và công sức để xây dựng ý tưởng mà không nhận lại được gì.
Với ví dụ bên trên của lớp UXF, nếu Ông giáo đăng bài này, nhưng sớm hơn vài năm, có lẽ hiệu quả sẽ không được như thực tế. Còn nếu Ông giáo đăng bài này sau khi đã hoàn thành giáo trình, chuẩn bị sẵn sàng mọi thứ cho lớp học như địa điểm, website,… thì rủi ro sẽ rất lớn nếu không có ai đăng ký học.
Còn một điều là đừng ngại việc chủ động tìm kiếm sự cam kết. Người dùng có thể chấp nhận hoặc từ chối, nhưng đó không phải vấn đề. Không phải ai cũng sẽ chuyển đổi thành khách hàng của chúng mình. Điều quan trọng là chúng mình sẽ nhận ra mình đang đứng ở đâu trong trái tim người dùng.
Lời khuyên
Từ những ví dụ trên, chúng mình muốn rút ra kết luận rằng: Tìm kiếm sự cam kết của người dùng trước khi làm sản phẩm là một việc vô cùng quan trọng.
Việc này sẽ giúp chúng mình tiết kiệm được rất nhiều thời gian, chi phí và công sức khi làm sản phẩm. Đồng thời, nó cũng giúp tăng khả năng xây dựng được một tính năng, hay rộng hơn là một sản phẩm và dịch vụ thành công. Do đó, nghiên cứu và kiểm chứng cam kết của người dùng là việc chúng mình cần làm xuyên suốt quá trình phát triển sản phẩm.
See you ngày mai!
Bài viết này thuộc series Lúa hóa cuốn sách "The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you". Đây cũng là một hoạt động hàng tuần của Book Club trong diễn đàn UX Foundation, nơi các học viên tụ họp mỗi lần một tuần để thảo luận về cuốn sách mà mọi người cùng đang đọc.