#34 - Các lăng kính cần phải có khi làm sản phẩm

Mình thấy câu hỏi này pop up khá là nhiều, vì vậy mình viết bài này để cung cấp cho mọi người một số lăng kính hữu ích trong việc làm sản phẩm. Trong phần kết luận thì mình sẽ sử dụng nội dung bài viết để trả lời câu hỏi trên.

Mình cũng sẽ cung cấp một số góc nhìn mở rộng qua việc trả lời câu hỏi "What would a novice likely get wrong here?" ("một bạn mới thì sẽ dễ mắc lỗi gì?") đối với mỗi lăng kính. Đây là một câu hỏi mà theo kinh nghiệm của mình sẽ dễ đào ra được những góc nhìn hữu ích hơn.

🌊 Luồng công việc của người dùng

Quy trình làm việc của người dùng hiện tại là gì? Đây là một lăng kính cực kỳ căn cơ nếu bạn làm sản phẩm B2B. Đơn giản là vì nếu bạn không biết được luồng công việc mà khách hàng đang làm là gì, thì chắc chắn không thể làm ra được một sản phẩm phục vụ được nhu cầu tối thiểu của doanh nghiệp.

Điểm mấu chốt ở đây chính là quy trình làm việc của nhiều người trong một doanh nghiệp, khi kết hợp lại với nhau, thể hiện được cách mà doanh nghiệp vận hành. Khi hiểu được cách mà doanh nghiệp vận hành, bạn hình thành được một bản đồ ở trong đầu để hình dung và phân loại rõ ràng hơn các vấn đề hoặc nhu cầu mà họ nói ra.

Công ty hiện tại của mình - Holistics, làm sản phẩm trong mảng Business Intelligence. Rất nhiều tính năng trong sản phẩm của tụi mình phục vụ cho Data team, những người trực tiếp làm việc với dữ liệu.

Tuy nhiên, công việc của Data Team gắn liền với Business Stakeholders rất chặt chẽ. Một trong những công việc mà nhiều Data Teams phải làm sau khi xây dựng xong dashboards đó chính là hướng dẫn Business Users sử dụng. Có những Data Team họ book meeting rồi đi qua từng cái đồ thị để giải thích cho Business Users hiểu được ý nghĩa, cách sử dụng, và những use case hiện tại chưa giải quyết được.

Nhiều Data Teams rất quan tâm đến việc Business có thể tự sử dụng dashboards để tự trả lời các câu hỏi một cách hiệu quả hay không, bởi vì Data Team không muốn phải xử lý nhiều ad-hoc requests mà Business Users có thể tự tìm thấy câu trả lời, và nó cũng ảnh hưởng đến việc xây dựng văn hóa sử dụng dữ liệu cho toàn công ty.

Nếu chúng ta chỉ tập trung vào công việc của Data Teams mà thiếu đi góc nhìn về việc công việc của họ ráp vào luồng vận hành của doanh nghiệp như thế nào, thì sẽ rất khó để nhìn ra được những cơ hội mới.

Một trong những vấn đề hiện tại đó chính là Data Teams rất khó để biết được liệu Business Users có thật sự sử dụng dashboards mà họ làm ra hay không. Với một số công ty, dashboard adoption là một KPI quan trọng của Data Teams, vì nhiệm vụ của họ là giúp xây dựng và phổ biến văn hóa sử dụng data cho công ty.

Nếu không nắm bắt được khía cạnh này, chúng ta sẽ bỏ qua cơ hội làm tính năng để cho Data Teams thấy được các chỉ số liên quan đến dashboard adoption trong công ty của họ. Khi họ thấy chỉ số này thấp thì có thể nói chuyện với Business để tìm câu trả lời. Ngược lại, khi chỉ số này cao thì chúng ta có thể dùng nó để làm dấu hiệu cho thấy rằng công ty của khách hàng đang nhận được nhiều giá trị từ Holistics, từ đó mở ra các cơ hội upsell hay expansion.

Đương nhiên việc làm một tính năng gì đó hay không nó không chỉ phụ thuộc vào User Values, mà còn phải tính đến Business Value hay Strategic Value, nhưng nếu chúng ta không nhận thức được luồng công việc của người dùng một cách tổng quan, thì điều đó sẽ giới hạn lại khả năng tạo ra impact trong việc làm sản phẩm.

🏠 Mô hình dữ liệu

Dữ liệu ở đây mình không nói đến dữ liệu về cách người dùng sử dụng sản phẩm, mà đang nói về những khái niệm và dữ liệu cần thiết để người dùng đạt được mục đích công việc của họ. Một công cụ mà team BPM mình hay sử dụng đó chính là Conceptual Data Model, hay mô hình dữ liệu khái niệm, để miêu tả các dữ liệu liên quan và mối quan hệ giữa chúng.

Giả sử chúng ta đang xây dựng một ứng dụng du lịch giúp cho việc đặt phòng khách sạn. Conceptual Data Model sẽ mô tả các thực thể quan trọng và mối quan hệ giữa chúng mà không đi sâu vào chi tiết kỹ thuật (như kiểu dữ liệu hoặc khóa chính/phụ).

Giải thích kỹ hơn:

• Khách Sạn (Hotel) có nhiều Phòng (Room).
• Phòng (Room) có thể có nhiều Đặt Phòng (Reservation).
• Khách Hàng (Customer) có thể đặt Đặt Phòng (Reservation).
• Khách Hàng (Customer) cũng có thể là Khách (Guest).
• Khách Hàng (Customer) giao dịch với Khách Sạn (Hotel).

Lăng kính này giúp người làm sản phẩm hình dung rõ những thực thể nào cần được tham gia vào một tính năng mới và mối quan hệ giữa chúng.

"Thêm cái màn hình/cái nút/tính năng này chắc chắc dễ mà!" - một (phiên bản) câu nói của PM dễ làm cho developer tụt mood và giảm dần sự tôn trọng nhất. Đây cũng là sai lầm mà mình thấy nhiều bạn mắc phải. Lý do khá dễ hiểu vì dạng hình ảnh thì dễ dàng tượng tượng trong đầu hơn, còn vẽ conceptual data models đòi hỏi bạn phải tư duy trừu tượng và có tính hệ thống.

Chỉ vì giải pháp về mặt giao diện chỉ đơn giản là một màn hình đặt phòng, không có nghĩa là mực độ phức tạp của giải pháp thấp. Sau bao nhiêu năm làm sản phẩn thì mình nhận thấy điều ngược lại thường đúng hơn: khi một giao diện tinh gọn, dễ sử dụng và giúp cho người dùng đạt được mục tiêu công việc của họ, thì thường đội ngũ phát triển sản phẩm đã phải xử lý rất nhiều sự phức tạp ở đằng sau rồi.

Khi có một bức tranh tổng quan về các thực thể và mối liên hệ, PM có thể xác định rõ:

• Dữ liệu nào cần thu thập và đảm bảo tính toàn vẹn để tính năng hoạt động được? Ví dụ như chúng ta cần cần thông tin về phòng để tạo được một đơn đặt phòng.
  • Những dữ liệu về phòng ốc của khách sạn cần luôn được cập nhật, và chúng ta cần nghĩ đến những tình huống sự toàn vẹn này không được đảm bảo. Chuyện gì xảy ra nếu có một khách hàng nào đó đến lễ tân book phòng trực tiếp thay vì qua ứng dụng, và cùng lúc đó có một khách hàng khác book đúng ngay cái phòng đó qua ứng dụng? Bạn cần phải xử lý nguồn thông tin đặt phòng từ phía lễ tân như thế nào?
• Các mối liên kết giữa các khái niệm cần thiết để làm các tính năng cho đúng quy trình làm việc của khách sạn.
  • Customers chưa chắc là guests, vì vậy khi làm tính năng đặt phòng phải có một phần riêng để cho customers điền thông tin về khách ở , nếu không chúng ta sẽ không phục vụ được nhu cầu này.
  • Một công ty có thể đặt nhiều phòng cho nhân viên, cũng như một gia đình có thể đặt nhiều phòng cho nhiều thành viên khác nhau. Việc không hiểu được đúng các mối quan hệ giữa các khái niệm dẫn đến nhiều hệ lụy về sau.
• Hoạch định những thông tin cần phải có trên giao diện như hiển thị thông tin phòng, thông tin khách ở và chi tiết giao dịch trên một đơn đặt phòng.
  • Những thông tin này rất quan trọng để design có thể làm tốt nhiệm vụ của họ. Những khái niệm như "phòng" được thể hiện ở các chỗ khác trong ứng dụng như thế nào, và trong màn hình đặt phòng này thì có cần sự nhất quán trong design hay không.
• Đánh giá độ phức tạp của giải pháp: một giải pháp phải đụng đến nhiều concepts nhiều khả năng sẽ phức tạp hơn so với một giải pháp đụng đến ít concepts. Chỉ cần hình dung ra conceptual data models trong đầu thì mình đoán phải giảm thiểu đến 95% những case bạn bảo "làm cái này dễ lắm".

🔎 Lời kết

Hy vọng hai lăng kính ở trong bài viết giúp cho bạn có thêm những góc nhìn hữu dụng trong việc làm sản phẩm.

Việc hiểu được quy trình cũng như suy nghĩ về mô hình dữ liệu của các khái niệm trong cách mà người dùng thực hiện công việc của họ sẽ khiến cho bạn nhìn được nhiều khía cạnh hơn, để từ đó thiết kế giải pháp và luồng vận hành sản phẩm một cách tối ưu và toàn vẹn.

Với hai lăng kính trên, mình muốn mở rộng hơn về khái niệm lăng kính. Chúng ta hãy trở lại câu hỏi ban đầu.

"Nhiều tools/frameworks cho Product Managers quá, em có cần phải học hết hông? Rồi có các công ty mà họ không dùng những tools/frameworks này thì như thế nào?"

Câu trả lời của mình:

• ✅ Việc trang bị cho mình những lăng kính khác nhau là rất hữu dụng trong việc làm sản phẩm. Chúng ta học sử dụng các công cụ cốt là để rèn giũa bản thân nhìn thế giới qua những lăng kính đó một cách thuần thục hơn.
• ✋ Tuy nhiên, không nên quá tập trung vào công cụ, mà hãy thẩm thấu cái cách nhìn thế giới mà công cụ đó mang lại. Mỗi công cụ hay frameworks đều làm nổi bật một số khía cạnh của thực tại, đồng thời làm mờ đi những khía cạnh khác. Hãy xem công cụ như những lăng kính mà chúng ta có thể chủ động nhấc lên và dùng để quan sát đánh giá một tình huống. Và khi chúng ta thấy nó không hữu dụng thì hãy đặt xuống và dùng một lăng kính khác.
• 🤷 Nhiều frameworks/tools nó có cùng lăng kính nhưng chỉ khác hình thái thể hiện. Cũng như có những công ty họ không dùng các frameworks/tools phổ biến, nhưng vẫn có cách riêng của họ để nhìn thấy được những khía cạnh quan trọng trong việc làm sản phẩm, thì điều đó cũng hoàn toàn ổn.

Với góc nhìn trên, mình nghĩ cách reframe lại câu hỏi hay hơn đó là: