Tính năng sản phẩm

Đa số mọi người nghĩ về tính năng đầu tiên khi nói đến một sản phẩm

Bình thường khi người dùng được hỏi để phản hồi về một sản phẩm, họ thường tập trung đưa ra nhận xét rằng sản phẩm này nên có thêm tính năng nào, tính năng hiện có này nên hoạt động như thế nào mới đúng, giao diện nhìn chưa ưng ý,… Ví dụ như đây là một số Feedback của người dùng về ứng dụng Google Keep trên CH Play Store:

Hoặc khi tìm kiếm về một ví dụ về User Story trên mạng, hầu hết các ví dụ đều chỉ đang dừng ở mức thể hiện, các User Story này đều đang kể về việc người dùng đang muốn tính năng gì, và có tính năng đó thì người dùng làm được gì.
Vài hình ảnh về User Story mà tôi tìm được khi tìm kiếm trên Google:

Bạn có nhận ra được điểm chung của hai ví dụ trên? Đó là cả hai đều chỉ đang dừng ở mức mô tả tính năng (Feature) mong muốn chứ chưa thể hiện được lý do gốc rễ (root cause) tại sao phải làm các tính năng này. Tức là mới chỉ dừng lại được ở mức Cần phải làm gì (What), chứ không phải là tại sao phải làm như vậy (Why).

Bản chất của tính năng

Để phân tích kỹ hơn, chúng ta hãy cùng tìm hiểu tính năng là gì. Tính năng sản phẩm là một phần chức năng cụ thể có lợi ích hoặc tập hợp lợi ích tương ứng cho người dùng. Lợi ích (benefit) ở đây chính là giá trị mà người dùng thu được từ việc sử dụng chức năng đó.
Có khi nào bạn mua điện thoại mới về mà phát hiện trong máy được cài sẵn một đống ứng dụng lạ được cài sẵn theo máy, không biết để làm gì chưa? Tôi khá chắc là nhiều bạn sẽ tìm cách xóa ngay hoặc vứt chúng vào xó, dù cho các ứng dụng này giao diện cực kỳ thân thiên và đẹp mắt đi nữa, vì chúng chẳng có ích gì với chúng ta cả.
Như vậy người dùng chỉ sử dụng một tính năng khi mà nó có lợi ích cho họ. Điều này có nghĩa là, nếu một tính năng được xây dựng mà không đem lại giá trị cho người dùng, thì sẽ không được sử dụng, hoặc thậm chí mang lại ấn tượng cho người dùng. Và tính năng chỉ là một giải pháp (solution) mà chúng ta áp dụng để mang lại lợi ích cho người dùng.
Lý do mà hầu hết mọi người đều nghĩ ngay đến tính năng trước cho một sản phẩm:
- Tính năng là cái đầu tiên và rất dễ nhận biết khi quan sát một sản phẩm, những vấn đề và nhu cầu mà sản phẩm được ẩn sau các lớp này thì khó nhận biết hơn
- Ảnh hưởng của quảng cáo và marketing là tập trung vào giới thiệu các tính năng do nếu chỉ nói về giải quyết vấn đề của người dùng thì sẽ không có gì mới và hấp dẫn về mặt truyền thông.
- Con người khi nói đến mong muốn của mình thường muốn hiện thực hóa và có nhanh nhất có thể, nên sẽ nghĩ ngay đến tính năng đầu tiên.

Tư duy xây dựng sản phẩm

Để xây dựng được sản phẩm, có thể kể đến 2 cách thức được sử dụng nhiều nhất:

Tại sao không nên xây dựng sản phẩm theo Feature-base?

Chỉ tập trung làm theo Tính năng rất dễ xa rời người dùng

Being a product manager is all about finding a solution to a problem, instead of trying to fit the problem to a solution
Do đặc tính của Feature-base là bạn quyết định giải pháp và giả định rằng giải pháp này giải quyết định đúng và đủ vấn đề của người dùng, nên nếu bạn thành công, bạn phải rất may mắn!
Bởi vì hầu hết các Feature này được xây dựng theo giả định, và giả định thì thường sai nên việc các tính năng được xây dựng ra không phù hợp gì cả với người dùng là rất phổ biến.

Xây dựng tính năng một cách mù quáng

Thực tế có nhiều nơi mà tôi biết đều chạy theo xây dựng theo tính năng. Product Roadmap của họ là những thanh dài thể hiện các tính năng mà công ty sẽ xây dựng cho sản phẩm theo mong muốn của ban lãnh đạo chứ không phải là các tính năng được thảo luận kỹ nhằm giải quyết đúng vấn đề của người dùng.
Điều này là do những người có vị trí cao và tiếng nói trong công ty có sức ảnh hưởng lớn đối với việc phát triển hệ thống đều nhìn theo góc nhìn tính năng trước, bởi vì nó rất dễ trong việc giao việc xuống dưới, nhận xét sản phẩm, hay so sánh với đối thủ cạnh tranh bằng tính nắng.
Như vậy, team xây dựng sản phẩm ở dưới sẽ phải chạy theo việc xây dựng sản phẩm một cách mù quáng theo chỉ đạo ở trên để thỏa mãn như cầu của ban lãnh đạo hoặc để đạt được KPI.

Khó phát triển lên và tốn kém sau này

Bạn hãy tưởng tượng khi bạn lên kế hoạch xây dựng một ngôi nhà, nếu bạn xây dựng phần móng rất vững chắc, sau này khi bắt đầu xây dựng cao lên sẽ rất dễ. Tuy nhiên nếu bạn xây dựng một sản phẩm với nền móng không ổn định, thì khi xây dựng thêm, sẽ rất khó khăn, thậm chí phải đạp đi xây lại.
Xây dựng sản phẩm cũng như vậy, khi ấy bạn ko chỉ bị nợ công nghệ (technical debt) đè nặng, mà còn bị vấn đề về văn hóa công ty đã bị ảnh hưởng, cũng như đội ngũ làm sản phẩm bị hổng kiến thức về người dùng và rất thụ động. Khi ấy rất tổn kém cả về chi phí và thời gian để sữa chữa.

Tư duy xây dựng sản phẩm là Problem Solving

Như đã phân tích ở trên, chúng ta nên xây dựng vấn đề đi từ Problem-base trước. Điều này đồng nghĩa với việc, để xây dựng được một sản phẩm thành công, thì bạn phải luôn hướng đến xây dựng một sản phẩm mang lại lợi ích cao nhất cho người dùng.
Lợi ích = Giá trị nhận được - Công sức bỏ ra
- Tăng tối đa giá trị đạt được: Đáp ứng nhu cầu người dùng bằng cách giải quyết vấn đề của người dùng và thỏa mãn mong muốn của người dùng
- Giảm thiểu công sức bỏ ra của người dùng tối đa: Đưa ra các giải pháp thật tối ưu (trong đó có xây dựng các tính năng phải thật tuyệt vời và dễ sử dụng)
Để làm được điều này, tư duy Problem Solving cực kỳ hữu dụng, bởi vì nó hỗ trợ cả hai thứ:
1. Cách tìm ra đúng vấn đề cốt lõi cần giải quyết, như vậy giá trị nhận được sẽ cao hơn.
2. Tìm ra giải pháp tối ưu, công sức và sự thỏa mãn của người dùng cũng sẽ tăng tương ứng.
Như vậy, tư duy xây dựng sản phẩm nên là Problem Solving, tức là hướng theo Problem-base làm gốc, chứ không nên tập trung trước vào Feature-base.

Áp dụng Problem-base và tư duy Problem Solving vào xây dựng sản phẩm

Requirement, User Story, Epic là problem chứ không phải là feature

Người dùng có thể quyết định chọn sản phẩm của bạn nếu nhìn thấy danh sách những tính năng hay ho và hoành tráng, nhưng điều giữ người dùng ở lại đó chính là vấn đề/nhu cầu của người dùng được sản phẩm của bạn giải quyết một cách đầy đủ và đem lại giá trị nhiều nhất.
Có khi nào bạn mua điện thoại mới về mà phát hiện trong máy được cài sẵn một đống ứng dụng lạ được cài sẵn theo máy, không biết để làm gì chưa? Tôi khá chắc là nhiều bạn sẽ tìm cách xóa ngay hoặc vứt chúng vào xó, dù cho các ứng dụng Icon, giao diện có đẹp đến mức nào đi nữa, vì chúng chẳng có nhu cầu để dùng làm gì cả.

Tư duy khi làm sản phẩm nên đánh đúng vào nhu cầu này của người dùng. Hãy cùng nhau đi qua một ví dụ với User Story đơn giản về việc cho phép người dùng đăng nhập vào hệ thống cho phép quản lý Tài chính cá nhân. Bình thường các bạn PM mới hay viết ngắn gọn là:
As a registered user, I want to login, so that I can access to the app.
User Story trên bị rơi vào 2 lỗi lớn:
Quá mơ hồ, không đem lại giá trị gì nhiều cho người đọc. Nó giống như kể một câu chuyện mà người nghe bị hụt hẫng do kết bài lơ lửng. Tôi biết là cần đăng nhập rồi, mà chỉ có nhiêu đó thông tin thôi sao?Đây là Task, chứ không còn là một User Story nữa. Do nội dung của nó chỉ nêu thẳng ra Feature cần xây dựng, chứ không phải là một đề bài yêu cầu để team phát triển có thể “develop” đúng nghĩa (cùng bàn luận, tìm ra giải pháp, xây dựng, thử nghiệm,…).
Khi tìm hiểu về vấn đề này, thường tôi hay sử dụng phương pháp “3 lần why” (tất nhiên không phải lúc nào cũng chính xác là hỏi 3 lần why), tức là phải tìm hiểu về tận gốc vấn đề:

Như vậy, tôi có thể viết lại User Story như sau:
As a registered user, I want to securely login the app.
So that:
My information can only be accessed by meMy data can be synced and accessed across different placesI have a dedicated profile to receive better promotion, offer and customer service.
Với user story này, câu chuyện mà chúng ta muốn kể đã rõ ràng hơn, người đọc thật sự hiểu được câu chuyện đằng sau User Problem này, cũng như “đất diễn” cho team phát triển cũng lớn hơn rất nhiều, mọi người sẽ biết lý do tại sao và hứng thú hơn trong việc tìm ra giải pháp, biết được phạm vi và những yêu cầu cần đạt được khi giải quyết vấn đề.
Ngoài ra đối với các team giỏi, các bạn còn có thể lên kế hoạch và chuẩn bị trước được cả kiến trúc hạ tầng cho sản phẩm để phục vụ cho việc bảo mật và sync data cho người dùng chỉ nhờ việc đọc User Story này.
Như vậy, cách bạn tìm ra được đúng vấn đề và truyền đạt được chính xác tới team có thể đã đảm bảo được tới 60% thành công của sản phẩm.

Hiểu rõ bản chất vấn đề cho cái nhìn bao quát hơn

Bạn có bao giờ tự đặt ra câu hỏi, tại sao một vấn đề xảy ra, bạn không thể kiểm soát được hoàn toàn, luôn xảy ra vấn đề ở một chỗ nào đó mà tôi không biết được. Hay là làm sao tôi biết được điều mà tôi không biết?
Vấn đề này xảy ra rất nhiều ở các công ty Startup. Ví dụ như ở một công ty về thương mại điện tử, bộ phận thương mại chịu áp lực rất lớn về việc phải bán được thật nhiều hàng, chính vì thế nên các bạn cố gắng thử nghiệm rất nhiều cách thức khuyến mãi, phương thức quảng cáo, trò chơi,… Nên từ đó mà số lượng các chương trình cũng như khuyến mãi dành cho khách hàng là nhiều vô số kể, tất nhiên là mục tiêu đạt được, công ty phát triển về doanh số, tuy nhiên rất nhiều bộ phận khác phải gánh chịu sau đó:
- Vận hành: Ủa cái chương trình khuyến mãi này đâu ra vậy? Sao hệ thống không hiển thị, rồi chúng tôi phải xử lý sao? Mấy đơn này hết sản phẩm tặng kèm rồi, làm sao nhập cho kịp đây?
- Pháp lý: Mấy chương trình này chưa đăng ký với Sở công thương mà, chạy rồi giờ tính sao đây?
- Kế toán: Mấy đống Voucher code này là gì thế, giờ tính toán để ghi sổ bút toán cho nửa triệu đơn hàng mới phát sinh này vào hệ thống sao giờ, ngày mai là đóng sổ rồi?
Nhiều người bảo đây chính là văn hóa Startup, chính là hỗn loạn và phát triển nóng. Nhưng tôi nhìn với một góc nhìn khác, ở đây mọi người làm sản phẩm mà chưa đủ tử tế. Khi chuẩn bị cho một tính năng mới, nếu người chịu trách nhiệm chịu dành thêm thời gian để có một cái nhìn tổng quát, hiểu rõ và lên kế hoạch thật kỹ, thông báo và đưa các bên liên quan đầy đủ vào để nắm thông tin và chuẩn bị trước (Ví dụ như Vận hành, pháp lý và kế toán ở trên), thì mọi người sẽ lường trước được và tránh được rất nhiều rủi ro sau này. Do chi phí sửa chữa vấn đề luôn luôn đắt hơn rất nhiều chi phí chuẩn bị, đề phòng từ trước.
Hiểu tường tận về gốc rễ vấn đề của người dùng cũng chính là hiểu về bản chất khi chúng ta muốn xây dựng một sản phẩm. Khi hiểu được bản chất, bạn sẽ có được cái nhìn bao quát, khi ấy bạn sẽ là một người Product Manager thực thụ, là một Product leader dẫn dắt, đưa ra định hướng và kiểm soát, biết  được cần phải làm gì.

Giải quyết gốc rễ vấn đề mới giá trị

Hãy cùng nhau giả định bạn chịu trách nhiệm cho một hệ thống Quản lý đơn hàng (Order Management System). Hệ thống này chủ yếu được sử dụng bởi đội vận hành, gần như mọi nghiệp vụ xử lý và tra cứu thông tin đều được thực hiện trên đây. Nên hệ thống được đặt ra yêu cầu là phải hoạt động cực kỳ ổn định và xảy ra càng ít sai sót từ thao tác người dùng càng tốt.
Tuy nhiên, đời không như là mơ, không hệ thống nào mà không có lỗi hoặc vấn đề cả.
There's always one more bug.
- Lubarsky's Law of Cybernetic Entomology
Khi hệ thống xảy ra vấn đề, là mọi người bắt đầu nháo nhào lên, do lỗi này ảnh hưởng đến cả một chuỗi xử lý phía sau, rất nhiều người phải đứng không để đợi và khách hàng sẽ không được nhận hàng đúng giờ. Điều này dẫn đến áp lực rất lớn đối với các bạn quản lý vận hành, các bạn có trách nhiệm phải tìm cách giải quyết được vấn đề ngày trong thời gian ngắn nhất để guồng máy hoạt động trở lại.
Chính vì vậy mà những yêu cầu được đưa tới cho Product cũng rất gấp và thường là các đề xuất về giải pháp ngắn hạn (workaround). Ví dụ như: Có thể cắt bớt bước này trong quy trình xử lý được không, tức là hệ thống không yêu cầu phải làm bước này nữa mà có thể đến ngay bước sau, team có thể theo dõi tay, do hiện tại ở chỗ này hệ thống không quét được mã vạch.
Nếu các bạn chạy theo giải quyết vấn đề y chang như vậy, thì có thể về ngắn hạn sẽ giải quyết được, tuy nhiên lâu dài những lỗi này vẫn sẽ lặp lại, và thậm chí còn phát sinh thêm nhiều lỗi và gánh nặng khác sau này, như nếu cắt bớt bước như trên thì sẽ gây ra vấn đề về gian lận như nhân viên xử lý đơn hàng sẽ lợi dụng lỗ hổng để ăn cắp hàng, hoặc bị lủng thông tin khi tính toán số tiền để thanh toán hoặc hoàn trả cho khách hàng. Bởi vì:
- Cái mà bạn đang cố gắng giải quyết chỉ là Triệu chứng của vấn đề, giống như uống thuốc cảm cúm chỉ là giảm bớt các triệu chứng của bệnh mà thôi
- Giải pháp được đưa ra hầu hết trường hợp đều không phải là giải pháp tối ưu nhất

Ở đây, khi bình tâm lại, dành thêm một chút thời gian để tìm hiểu về gốc rễ vấn đề, thì lý do là do dòng máy cầm tay mới mà đội vận hành mua về không tương thích với phần mềm hiện tại nên xảy ra lỗi khi quét mã vạch. Nếu mà cứ giữ như vậy thì rất có thể lỗi này sẽ còn phát sinh ở các bước khác chứ không chỉ ở bước đã nên.
Giải quyết vấn đề này không khó, bạn kỹ sư phần mềm kiểm tra lại là chỉ cần nâng cấp phiên bản của thư viện quét mã camera là xong, chỉ mất 5 phút! Và vấn đề này không bao giờ xảy ra nữa.
Tiếp theo
Chúng ta đã tìm hiểu tại sao tư duy làm sản phẩm phải là Problem Solving. Vậy tìm ra cách giải quyết như thế nào khi đã xác định đúng Problem? Chúng ta sẽ cùng tìm hiểu về Design Thinking, nó khác gì với cách giải quyết vấn đề truyền thống.