Startups và Những Công Việc Không Scale Được (Phần II)

Oct 02, 2024

Lời mở đầu

Mình và

đang làm một sản phẩm công nghệ riêng là A Little Optimism, với tâm thế chia sẻ những bài học của tụi mình khi “nuôi đứa con” này tụi mình đã kể sơ qua những công việc unscalable (các giải pháp không phổ biến, khó scale lên, nhưng mang lại kết quả rất hiệu quả trong một ngữ cảnh rất cụ thể) thủa khai hoang của sản phẩm ở Phần I.

Trong phần II, tụi mình sẽ cho các bạn một cái nhìn cận cảnh vào hành trình của một chức năng mới gần đây: “People mentioning” - Nhắc đến những mối quan hệ trong lịch sử biết ơn. Đây sẽ là một quá trình rất chi tiết làm chức năng từ khâu ý tưởng, validate (xác nhận) những nhu cầu, thiết kế, thực hiện, thiết kế metrics. Đúng với tinh thần unscalable, quá trình không tuân theo một framework nào một cách nghiêm ngặt mà tụi mình sẽ chắc lọc những tinh túy từ những gì tụi mình tự học được để đưa ra giải pháp phù hợp nhất với bối cảnh của A Little Optimism bây giờ.

Trước khi đi vào câu chuyện vô cùng gian truân thì mời các bạn xem video ra mắt sản phẩm trông (có vẻ) khá xịn của tính năng để dễ hình dung ra hơn:

Mình sẽ kể lại theo trình tự mà chức năng này được phát triển:

I - Tại sao chúng mình lại có ý tưởng này

II - Tìm ra những nhu cầu phổ biến

III - Validate và chọn ra nhu cầu đáng giải quyết nhất

IV - Triển khai với nhiều lần lặp cải tiến

V - Đặt ra những metrics từ strategy

VI - Time-box để lấy bài học

VII - Lời kết & Bài học

Một chút bối cảnh về A Little Optimism: Là một sản phẩm áp dùng positive psychology intervention (can thiệp tâm lý tích cực) để giúp những người đã/đang/sẽ đạt nhiều thành tựu giữ được sự bền bỉ trong sức khỏe tinh thần thông qua việc thực hành biết ơn mỗi ngày cùng với một partner ngẫu nhiên.

Chức năng này cho phép người dùng gắn tag (thẻ), hoặc nhắc đến người thân, sau đó trong phần lịch sử sẽ thấy được mình đã có những kỉ niệm đẹp cùng với ai. Trước khi vào chi tiết, các bạn thử đoán xem đối với một chức năng nho nhỏ này, từ khâu ý tưởng cho tới khi thành phẩm hết bao nhiêu thời gian nhé?

I - Tại sao chúng mình lại có ý tưởng này

Đầu tiên là nhu cầu tăng trưởng, giai đoạn này nên được tập trung khi sản phẩm đã đạt được retention rate tốt (tỉ lệ giữ chân người dùng). Các bạn có thể xem thêm về AARRR - Pirate Metrics Framework nha. Nói dễ hiểu thì khi giữ chân được người dùng rồi thì mới thu hút nhiều người dùng mới, nếu tập trung thu hút người dùng quá sớm sẽ giống như đựng vàng vào túi ba gang thủng ấy.

Đối với những sản phẩm công nghệ thì mức retention rate tốt sẽ lớn hơn 20% trong vòng 8 tuần (Các bạn có thể xem thêm ở đây nếu muốn học chi tiết hơn). Retention rate của A Little Optimism rơi vào khoảng 20%~30%, đạt được chỉ tiêu mà tụi mình đề ra.

Do sản phẩm của tụi mình là non-profit, nên đến đây thì mình coi như đã có đủ 2 trong 3 thành phần khi xác định vấn đề là Strategic Fit và Business Value (đọc thêm về 3 thành phần). Phần mình còn phải tìm kiếm là User Value (giá trị người dùng).

Về giá trị người dùng của sản phẩm, vốn phương pháp tụi mình áp dụng vào sản phẩm đã được chứng mình giúp người dùng tăng mức độ hạnh phúc và mang các hiệu ứng cảm xúc tích cực trong dài hạn.

Tuy nhiên giá trị này người dùng chỉ nhận được khi sử dụng liên tục trong vòng 6 tuần. Đó là một khoảng thời gian nghe khá “mất kiên nhẫn” đối với những sản phẩm consumer (là những ứng dụng phục vụ nhu cầu hàng ngày của người dùng, thường đòi hỏi phải tạo ra sự phấn khích ngắn hạn để thu hút và giữ chân người dùng).

Mình cần tìm được một giá trị nào đó mang tính đầu tư nhưng đồng thời dễ nhận biết, “cầm nắm” dễ hơn, và trực quan hơn. Ví dự như Tiktok có giá trị đầu tư là thuật toán dần được tối ưu tiệm cận với sở thích của bạn, Messengers thì chính là những cuộc hội thoại, những kí ức vui vẻ, kỉ niệm của các bạn trên đó.

Nhìn vào những gì tụi mình đang có ở trên sản phẩm là những điều mà người dùng cảm thấy biết ơn, mình tự hỏi có thể khai thác được những điều gì từ những tài nguyên có sẵn này?

Hạt giống ý tưởng đầu tiên về việc gắn thẻ đến từ câu chuyện của Thành. Khi muốn biết được những điều tốt xảy ra quanh một khía cạnh cụ thể, Thành sẽ phải đi lục lọi trong lịch sử biết ơn và đọc từng dòng một. Khi bạn xem lại lịch sử biết ơn của mình được phân theo những khía cạnh này không những sẽ bớt đi công sức phải mò mẫm những dẫn chứng mà còn nhìn được rõ những khía cạnh nào đã tác động tích cực lên bản thân. Chỉ đơn giản thế thôi! Và ý tưởng sơ khai về một chức năng có thể được gắn thẻ, phân loại những điều biết ơn đã ra đời.

II - Tìm ra những nhu cầu phổ biến

Để một chức năng có đem lại giá trị người dùng thì không chỉ thể dựa vào một điểm dữ liệu hoặc một trường hợp sử dụng cụ thể, mà nó phải đạt được độ phổ biến nhất định.

Chúng mình cần một nhu cầu đủ phổ biến để chống lưng cho chức năng này. Từ nhu cầu đó sẽ định hướng không những là trải nghiệm giao diện, UX Writing (những nội dung văn bản xuất hiện trong quá trình người dùng trải nghiệm ứng dụng) mà sẽ còn ảnh hưởng cả những định vị khi đưa chức năng này ra thị trường. Nếu không có nó thì tụi mình chắc chắn sẽ gặp rắc rối khi quyết định hình thái của nó ra sao, trường hợp sử dụng như nào. Giả sử từ ý tưởng phân loại thì sẽ có nhiều hình thái của một chức năng có thể trở thành nhiều biến thể như sau:

Phân loại theo cách đánh thẻ:
Chức năng gắn thẻ của Dovetail
Nhập thẻ trực tiếp trong nội dung
Chức năng gắn thẻ trong nội dung của TikTok
Nhắc đến một người khác
Chức năng nhắc đến một người khác trên Facebook

Chiến thuật ở đây giống như framework Double Diamond, cố gắng tìm nhiều nhất những nhu cầu liên quan đến hành vi này (diverge - phân kỳ) , sau đó chọn ra nhu cầu có độ phổ biến cao nhất (converge - hội tụ).

Tụi mình đã bắt đầu khâu diverge thông qua ChatGPT, từ những trường hợp sử dụng của mình và Thành, mình nhờ nó đề xuất cho mình khoảng 20 nhu cầu có liên quan. Từ đó mình lọc ra ba nhu cầu (mình đánh giá) chất lượng nhất để đi validate (xác nhận):

Vượt qua sự hoài nghi và phát triển lại khả năng trân trọng chân thành
Nhìn thấy vẻ đẹp và ý nghĩa trong những khoảnh khắc khó khăn
Hâm nóng những mối quan hệ chân thành trong thời đại của những kết nối hời hợt

Tuy nhiên validate được những nhu cầu này sẽ tốn rất nhiều thời gian để interview (thường mất 4 ngày để setup và phỏng vấn) và nếu tạo survey thì tỉ lệ trả lời cũng sẽ không cao nên mình muốn có một phương pháp nào đó lean hơn.

III - Validate, chọn ra nhu cầu đáng giải quyết nhất

Bắt đầu từ ý tưởng của cuốn sách “Asking the Right Questions”, mình tin rằng việc đặt đúng câu hỏi có thể giúp phân tích, xác thực thông tin hiệu quả. Ánh xạ lên trường hợp cụ thể, tụi mình tin sẽ có một câu hỏi có thể giúp tụi mình xác định được vấn đề này có phổ biến không, có đáng để giải quyết không.

Và mình cố gắng viết nháp mỗi nhu cầu chỉ 1 câu hỏi, mỗi câu hỏi phải đạt được những tiêu chuẩn như sau:

Tiêu chuẩn 1 - Dựa trên thực tế: Những người làm product lâu sẽ không lạ gì với câu "when was the last time...." rồi, nó hiệu quả vì dựa vào những sự kiện thật của người dùng chứ không phải cảm quan của họ.
Tiêu chuẩn 2 - Dựa trên sự ảnh hưởng lên cảm xúc: Câu hỏi này phải validate được tác động tiêu cực lên cảm xúc của người dùng khi nhu cầu không được thỏa mãn. Giả thuyết ở đây là nếu nếu sự kiện diễn ra càng đau thì sẽ càng được nhớ sâu hơn, dễ dàng nhớ lại hơn.
Tiêu chuẩn 3 - Động lực giải quyết vấn đề: Nếu người dùng chưa thử giải quyết nhu cầu này bất cứ một lần nào, thì tỉ lệ rất cao là họ sẽ không sử dụng sản phẩm của bạn làm ra để giải quyết nhu cầu đó.

Từ đây thì mình suy ra được một bài quiz nhỏ để gửi cho những người bạn của mình ở Breaking into PM:

Nhu cầu 1️⃣: Vượt qua sự hoài nghi và phát triển lại khả năng trân trọng chân thành
- One-question: "Khi mọi người đọc tin nhắn này mọi người recall thử giúp em một event mà mọi người thực sự appreciate (ghi được chi tiết tại sao mọi người appreciate, hậu quả sẽ như nào nếu không có điều đó)"
Nhu cầu 2️⃣: Nhìn thấy vẻ đẹp và ý nghĩa trong những khoảnh khắc khó khăn
- One-question: "Mọi người có cố tìm những kỉ niệm đẹp, những nội dung tích cực trong lúc unsettle không?"
Nhu cầu 3️⃣: Hâm nóng những mối quan hệ chân thành trong thời đại của những kết nối hời hợt
- One-question: "Có mối quan hệ nào của mọi người mà nó cứ nhạt dần mà không thể cứu lại được bằng việc liên lạc qua mạng xã hội không?"

Do chỉ có đúng một câu hỏi nên technique này giúp mình validate khá nhanh gọn, tỉ lệ mọi người trả lời cũng rất cao do, tổng cộng mình chỉ mất 30 phút từ khi mình đăng câu hỏi cho đến khi mình nhận được kết quả:

Và có thêm rất nhiều bạn sẵn sàng cho mình thêm những insight cụ thể về nhu cầu này:

“Cái số (3) thì situation dính đến cái em quan tâm và hay reflect để tìm ra nguyên nhân mà khắc phục cho các mối quan hệ sau. Nên đúng là vừa đọc xong thì ngay tức khắc nghĩ ra ngay”
“Cái (3) đọc 1 cái là mặt mấy người bạn đó hiện ra với chị luôn á”

Có kết quả, tụi mình chốt định hướng ý tưởng này đi phục vụ nhu cầu: Hâm nóng những mối quan hệ chân thành trong thời đại của những kết nối hời hợt.

Khi viết nó dưới dạng Job Story thì sẽ là như này:

Khi tôi nhận thấy nhiều mối quan hệ đã mờ nhạt đi, không thể giải quyết được bằng các mạng xã hội, phương tiện giao tiếp điện tử hiện tại. Và tôi may mắn vẫn có những quan hệ chân thành có thể bị phai mờ theo thời gian

Tôi muốn ôn lại những khoảnh khắc đáng nhớ với họ

Để tôi không mất đi các mối quan hệ chân thành
trong thời đại của các kết nối hời hợt

Chi tiết của technique này tụi mình sẽ thử sai và hướng dẫn các bạn ở một blog khác, “khi nào?” thì substack sẽ thông báo cho các bạn nếu các bạn đã subscribe, hehe.

IV - Triển khai với nhiều lần lặp cải tiến

Ở đây mình xin phép đi qua nhanh để các bạn thấy sự hình thành một cách gian khổ của một chức năng như nào chứ không phô trường kĩ năng làm UX của tụi mình (vì tụi mình cũng không có, hehe)

Bản đầu tiên chúng mình sử dụng là bản của Thành, và đây là màn hình chính của chức năng:

Một kiếp nạn lớn là việc thiết kế bản đầu tiên là định dạng dữ liệu sử dụng đang khác với dữ liệu trên bản hiện tại với người dùng. Sau nửa ngày vừa khóc vừa tìm cách khắc phục mình đã phải đưa ra quyết định là làm lại một bản khác từ đầu, giữ lại vài phần liên quan đến giao diện. Kèm thêm đó là một số cắt tỉa để giao diện của sản phẩm được gọn hơn do giao diện rất ít đất diện nên tụi mình luôn phải tối ưu thông tin đưa đến người dùng.

Và đây là bản chỉnh sửa đầu tiên:

Với nhu cầu Hâm nóng những mối quan hệ chân thành trong thời đại của những kết nối hời hợt, chúng mình muốn thể hiện được độ sâu của từng mối quan hệ trong những phần tag. Vậy những đặc điểm nào của tag này có liên quan độ sâu của mối quan hệ?

Ứng cử viên sáng là số lượng những điều biết ơn diễn ra trong phần lịch sử, và sử dụng màu để thể hiện tần suất xuất hiện của những người này trong lịch sử. Tuy nhiên chỉ thể hiện bằng con số sẽ khá khô khan và tốn diện tích, nên mình đã chọn cách biểu diễn tần suất này thông qua độ đậm nhạt của tag. Đây là bản chỉnh sửa thứ hai:

Tuy nhiên là đẹp nhưng bạn thử đoán xem chức năng này đang có vấn đề gì ở trong phần tương tác qua lại với người dùng?

Vấn đề ở đây là nhưng tương tác này khá “khô”. Và đây là cách tụi mình làm nó bắt mắt thêm một xíu ở bản cuối cùng:

Và đó là bề nổi của tảng băng. “Phần chìm” sẽ thú vị hơn khi các bạn đã làm ở những vị trí cao hơn trong môi trường quản lý sản phẩm như là Product Manager hoặc là Senior Product manager trở lên.

V - Đặt ra những metrics (thước đo) từ strategy (chiến lược)

Có một nguyên tắc của mình khi làm sản phẩm là luôn “đặt bẫy” cho những bài học, nó là một bước quan trọng trong triết lý “Close the loop”. Những cái bẫy là những metrics cho chức năng, nó đóng vai trò như một bản đồ đơn giản để điều hướng sản phẩm, để theo dõi được tụi mình có đạt được chiến lược đã đề ra ban đầu không?

Kể cả không đạt được đi chăng nữa thì mình cũng sẽ có những bài học về thất bại để tránh thất bại thêm ở nhưng lần sau. Nếu tụi mình chỉ có lập trình và ném các chức năng ra ngoài mà không có những phản hồi (bao gồm cả phản hồi từ người dùng và từ việc product analytics - phân tích và thống kê) thì mình sẽ rơi vào trạng thái thất bại mà không rõ nguyên nhân. Và chẳng có gì đảm bảo được là lần sau tụi mình sẽ tránh được những thất bại có cùng với nguyên nhân.

Vậy câu hỏi tiếp theo là “Mình sẽ phải đo đạc sự thành công của chiến lược này như nào?”, Chiến lược mình đưa ra tương đương với động lực ban đầu của mình đã nói về tăng trưởng lượng người dùng và phục vụ nhu cầu Hâm nóng những mối quan hệ chân thành trong thời đại của những kết nối hời hợt. Và đứng về góc độ hành vi người dùng thì chặng đường này sẽ khá dài:

Hành động đầu vào: Nhập một thẻ
Hành động trung gian:
- Click vào một tag
- Click vào các tag có nhiều lượt nhắc đến
Hành động resonate (gây cộng hưởng) mạnh nhất: Chia sẻ

Xong phần high-level, tụi mình đi giải tiếp câu hỏi về chi tiết các thông tin được lưu trong từng sự kiện tương tác. Từ những sự kiện như “click”, “input”… tụi mình sẽ phải theo dõi những thuộc tính gì trong muôn vàn thuộc tính trừ những thuộc tính bắt buộc như ID người dùng, thời gian xảy ra sự kiện. Nó tương đương với những câu hỏi:

Có cần lấy giá trị của tag không?
Số lượng tag xuất hiện trong input có quan trọng không?
Số lượng tag xuất hiện trong history có quan trọng không?
Việc lọc nhiều tag một lúc có quan trọng không?
….

Sau khi bóc tách nhu cầu cần giải quyết, tụi mình đã chọn được những tập câu hỏi sau đây để làm các metrics tương ứng:

Người dùng có nhập tag hay không?
Nếu dùng thì tần suất có nhiều không?
Người dùng có xem lại những chiếc tag này không?
Và họ có quan tâm tới 1 số người thì họ có xem đi xem lại không?

Mình sẽ bỏ qua phần chi tiết của những sự kiện tương tác để tránh gây lú và tập trung vào một bài học tụi mình áp dụng cho sự kiện tương tác “Share”

VI - Time-box để lấy bài học

Như bạn đã thấy hành động cao nhất chính là “share” nhưng tụi mình đã dành hết quỹ thời gian của chúng mình cho chức năng, và khi mình khảo sát nhanh độ khả khi về mặt kĩ thuật thì nó không dễ gì đối với những người không có kinh nghiệm lập trình quá cao như tụi mình.

Sau đó mình nhìn lại thì thấy còn quá nhiều assumption mà tụi mình có:

Liệu người dùng có nhập tag không?
Liệu người dùng có dùng chức năng history không? (tag được hiển thị trong phần history)
Liệu người dùng có quan tâm đến những tag này trong history không?

Chỉ một trong những assumption này mà nhận về câu trả lời “không” thì dù cho chúng mình làm thêm chức năng share thì cũng vô nghĩa. Vậy nên chúng mình đã chọn thảy luôn ra thị trường để xem mọi người dùng như nào?

Nếu hỏng thì chúng mình lại tìm cách khác, nếu ngon thì chúng mình sẽ làm chức năng share này ngay.

VII - Lời kết & Bài học

Cảm ơn và khâm phục các bạn khi đã đọc đến tận phần này, bài học của chúng mình rút ra được từ đây là:

Qua hành trình xây dựng chức năng "People mentioning" trong A Little Optimism, tụi mình đã rút ra được nhiều bài học giá trị từ những thử thách, sai lầm, và cả những lần điều chỉnh tinh tế:

Luôn xác định nhu cầu cụ thể: Dù là ý tưởng ban đầu có hay đến đâu, việc xác định đúng nhu cầu người dùng mới là điều cốt lõi để sản phẩm tồn tại bền vứng và tạo nền tảng tốt cho quá trình triển khai.
Áp dụng linh hoạt các kĩ thuật: Việc sử dụng những câu hỏi chính xác, ngắn gọn để validate nhu cầu không chỉ tiết kiệm thời gian mà còn mang lại hiệu quả cao. Cách tụi mình sử dụng một câu hỏi duy nhất cho mỗi nhu cầu đã giúp đẩy nhanh quá trình thu thập phản hồi, tăng tỉ lệ phản hồi từ người dùng.
Triển khai theo cách thử sai: Chức năng được thiết kế và lặp lại nhiều lần, từ việc định hình ý tưởng đến giao diện, luôn cần thời gian để tinh chỉnh và hoàn thiện. Những ý tưởng hay thường không xuất hiện ngay từ đầu mà xuất hiện khi đang triển khai một ý tưởng khác.
Đặt bẫy học hỏi thông qua các thước đo: Mọi chức năng đều cần những metrics rõ ràng để đánh giá hiệu quả. Việc phân tích những hành vi người dùng thông qua các hành động như nhập tag, click tag, đều giúp tụi mình nắm rõ hơn về mức độ thành công/thất bại của ý tưởng. Cung cấp đầu vào cho những đợt chỉnh sửa sau.
Chấp nhận time-box và thử nghiệm: Không phải lúc nào mọi thứ cũng diễn ra như kế hoạch. Việc chấp nhận giới hạn về thời gian và nguồn lực, dừng lại ở mức “good enough” đã đưa sự chú tậm về việc thu thập validated learning (bài học thực tế) thay vì thỏa mãn sự hoàn hảo chưa cần thiết.

Câu trả lời cho câu hỏi ở đầu blog: Tổng thời gian tụi mình làm hết tròn 2 tuần: trong đó chỉ có mất 3 ngày cho việc phát triển những chức năng chính, còn lại là cho phần làm đậm không gian vấn đề và làm metrics. Nó có khác nhiều so với bạn nghĩ không? Các bạn đang làm product như nào? Subcribe và comment cho tụi mình biết thêm những góc nhìn khác nữa nhá. 🫡

Eton on Product Games

Discussion about this post