Vài tháng trước, trong bài viết Những thứ về Problem Space trong quản lí sản phẩm mà mình biết, mình có thử trả lời câu hỏi "Một Product Manager giỏi là một người như thế nào?"

Trong bài đó, mình có chia sẻ là người Product Manager giỏi là một người mô tả vấn đề. Qua bài viết đó, mình có đưa một số công cụ / những tạo vật quan trọng các bạn thường dùng để mô tả Problem Space, bao gồm customer requests, mô tả bối cảnh quy trình workflow của users, hay mô tả bối cảnh thị trường.

Mình tin rằng khi một vấn đề được mô tả đủ tốt, nó trở thành một công cụ alignment cực kỳ mạnh:

• Giúp cả team nhìn về cùng một hướng
• Giảm hiểu lầm trong giao tiếp
• Và xử lý được rất nhiều xung đột ý tưởng giữa các team members

Sau bài viết đó, mình bắt đầu chú ý nhiều hơn tới kỹ năng trình bày vấn đề, và chủ động quan sát cách các quản lý cấp trên trao đổi những vấn đề mang tính chiến lược.

Khi sang làm ở công ty mới, mình có cơ hội quan sát kỹ năng này rõ ràng hơn khi làm việc với nhiều anh chị manager ở các phòng ban khác nhau. Khi trao đổi với các anh quản lý cấp cao, mình thấy các anh mô tả vấn đề rất gãy gọn, có định hướng rõ ràng: product đang ở đâu, đang gặp thách thức gì, và cần đi tới đâu.

Ngược lại, khi làm việc với các bạn junior, kỹ năng trình bày vấn đề này thường kém nổi trội hơn so với kỹ năng execution (làm cái gì, chỉnh chỗ nào, sửa ở đâu).

Ngoài ra, mình cũng nhận ra rằng Problem Space không chỉ nằm ở user, mà còn nằm ở:

• Thực trạng product hiện tại và lịch sử của nó
• Mô hình vận hành của team
• Và các ràng buộc tổ chức

Tất cả những yếu tố này đều cần được mô tả rõ khi nói về một vấn đề.

Với mục tiêu level up và nâng cao suất ăn cho các bạn độc giả, trong bài viết này mình sẽ chia sẻ thêm những kỹ thuật mô tả vấn đề mình học được và chưa chia sẻ ở phần 1. 😂

Problem Space cần phát biểu được hiện trạng và mục tiêu

Một trong những đặc tính quan trọng của Problem Space là Problem Space cần mô tả được hiện trạng và mục tiêu.

Nếu bạn nào có cày các sách hay blog về product thì rõ ràng khái niệm về Problem Space này không mới: Một vấn đề chỉ tồn tại khi có khoảng cách giữa trạng thái hiện tại và trạng thái lý tưởng.

Ví dụ đơn giản nhất là chuyện đói bụng:

• Hiện trạng: đang đói
• Mục tiêu: muốn no
• Giải pháp: đi ăn

Tuy nhiên, nói tới hiện trạng và mục tiêu thì nghe có vẻ rất hiển nhiên. Ai làm product cũng biết là một vấn đề chỉ tồn tại khi có khoảng cách giữa trạng thái hiện tại và trạng thái lý tưởng.

Hiện trạng và mục tiêu là cái outcome chứ không phải cái cần làm

Một vấn đề là mục tiêu thường bị nói thành việc cần làm, thay vì nói về kết quả cần đạt được.

Rất nhiều lần, khi bàn về một vấn đề, mình nghe những câu kiểu như: mục tiêu là "làm thêm onboarding", "mục tiêu là thêm tooltip", hay "mục tiêu là redesign lại flow này cho gọn hơn". Chúng đang nói về làm cái gì hoặc làm như thế nào, chứ chưa nói về sau khi giải quyết xong thì chuyện gì sẽ khác đi.

Mục tiêu trong Problem Space không phải là một to-do list, mà là cách mô tả outcome của vấn đề sau khi được giải quyết. Tức là: nếu làm đúng, thì user sẽ bớt kẹt ở đâu? Product sẽ vận hành khác đi như thế nào? Team sẽ biết mình đã tiến lên hay chưa dựa vào điều gì?

Ví dụ, thay vì nói “mục tiêu là làm onboarding”, thì câu hỏi nên là: sau khi xong, user có tự hoàn thành được bước quan trọng đầu tiên không? Có ít phải hỏi support hơn không? Có đạt được kết quả đầu tiên nhanh hơn trước không?

Khi mục tiêu được nói theo hướng outcome như vậy, rất nhiều thứ tự nhiên trở nên rõ ràng hơn. Team không còn tranh luận quá nhiều về việc nên làm onboarding, tooltip hay viết lại tài liệu, mà tập trung vào việc: làm sao để tạo ra sự thay đổi mong muốn đó.

Một số lỗi cơ bản khi mô tả Problem Space

Theo quan sát của mình, khi trình bày vấn đề, các bạn junior thường mắc một vài lỗi quen thuộc sau:

• (1) Mô tả vấn đề bằng một cái solution. Ví dụ: "Vấn đề hiện tại là mình chưa có một trang onboarding"
  • Câu này thực chất chưa mô tả vấn đề, mà chỉ đang nói rằng: Bạn đã nhảy thẳng sang Solution Space. Người nghe không hiểu onboarding này để làm gì, giải quyết vấn đề gì?
• (2) Mô tả vấn đề mà không có mục tiêu. Ví dụ: “Hiện tại user đang cảm thấy rất khó dùng, cần dễ dùng hơn.”
  • Khi nghe câu này, người nghe sẽ hỏi "Dễ dùng là như thế nào?", "Thành công được đo như thế nào", hay "Actionable ở đâu?"
  • Người nghe không biết mình cần phải làm gì, hay product cần đi tới đâu.
• (3) Mô tả vấn đề mà thiếu hiện trạng. Ví dụ: “Mình cần cải thiện trải nghiệm onboarding.”
  • Khi nghe câu nay, người nghe sẽ không biết "Hiện trạng onboarding như thế nào?", "User đang gặp khó ở bước nào", và "Có dữ liệu quan sát gì không?"
  • Người nghe không rõ hiện trạng của product đang như thế nào, và gap tới mục tiêu còn xa không.

Khi một vấn đề không được mô tả kỹ, team sẽ không biết product đang ở đâu, cần đi tới đâu, và feature build xong cũng không biết đánh giá thành công thế nào.

Ví dụ: Build ads system cho dbdiagram

Sau tết năm 2023, mình mới được nhận offer vào làm Product ở Holistics, cho sản phẩm dbdiagram.io và dbdocs.io.

Một trong những task đầu tiên mình được anh CTO giao là xây dựng một hệ thống ads và notification trên dbdiagram nhằm tận dụng lượng traffic lớn của sản phẩm này để cross-sell các sản phẩm khác trong hệ sinh thái Holistics.

Lúc đó, với tư duy còn rất nặng về execution, mình lập tức lao vào Solution Space và bắt đầu viết spec.

Trong spec của mình khi đó có hai ý chính:

1. Build một hệ thống ads / notification hiển thị bên trái khung code của dbdiagram
   • Ads có title, description và hình ảnh
2. Build một trang CMS để team có thể chỉnh sửa nội dung ads cho tiện

Để dễ hình dung, phiên bản đầu tiên của dbdiagram ad trông như thế này:

Lúc đó, mình đã design xong, mình đưa cho sếp coi và sếp cũng gật gù ok, tuy nhiên anh cũng không impressed lắm.

Lúc đó anh chỉ bảo mình là cần nhìn kĩ hơn từ high-level và viết lại thêm những tiêu chí em đặt cho cái ads này là như thế nào, bởi vì anh xem thì thấy cũng ok, nhưng anh không biết đánh giá như thế nào và tư duy về cái ads này ra sao.

Thật sự lúc đó mình cũng không biết phải làm gì, mình không biết đặt tiêu chí là như thế nào, vì đó giờ ai mình làm engineer nên ai cần build cái gì thì mình build, ra đúng cái spec là được, chứ làm gì có tiêu chí gì ở đây. Nên là anh cũng đưa 1 vài ví dụ luôn: "Ad này cần phải visible để ai cũng có thể thấy được", và " Ad này cần edit được dễ dàng bởi team marketing vì marketing là người chính dùng cái này", etc.

Lúc đó mình mới bắt đầu hiểu và bắt đầu build lại bộ tiêu chí của hệ thống ads này cho mình. Một cách chuẩn chỉnh hơn.

Lúc đó mình mới đào sâu và bắt đầu hiểu hơn vệ lịch sử của dbdiagrma ads lúc đó, và tại sao mình cần làm cái này. Mình mới nhận ra là thời điểm lúc đó hệ thống ads và notification của dbdiagram đã có sẵn, tuy nhiên về mặt hiện trạng đang có 1 số vấn đề:

• (1) Ads nằm phân mảnh khá nhiều nơi và gây rối mắt cho giao diện và user
• (2) Ads hiển thị không rõ ràng vì contrast chưa tốt giữa background, có khả năng không tối ưu về CTR
• (3) Việc chỉnh sửa ads hiện tại không dễ dàng vì ads được viết bằng code, và có thể khó khăn cho team marketing nếu muốn chỉnh sửa.
• (4) Không có metric rõ ràng để biết ads đang hiệu quả hay không

Từ những hiện trạng quan sát đó, mình mới cầm note lại 3 mục tiêu sau:

• Ads system cần phải được quy hoạch tập trung lại một chỗ để tránh gây rối mắt cho người dùng
• Ads system cần phải nhìn nổi bật để user có thể thấy và nhấn
• Ads system cần phải có thể edit được bởi team vận hành cái ads này, cụ thể là team marketing.

Từ đó Problem Space được hình thành như sau:

Đợt đó bởi vì trigger của bọn mình là để cross-sell Holistics trên dbdiagram, nên một trong những mục tiêu lớn của dbdiagram ads lúc đó là phải có conversion tốt, do mình mới thiết kế ads có màu sắc nổi bật, có kích thước to và bắt mắt.

Để dễ hình dung, ads lúc đầu trong như sau, có hình, có kích thước to và contrast lớn hơn hồi trước. Ads thì không tắt được bởi free users (phải trả tiền mới tắt được), notification thì ai cũng có thể tắt đươc.

(Ngoài những mục tiêu trên, mình còn 1 số mục tiêu khác như ví dụ như: User paid có thể tắt được ads, còn user free thì sẽ phải trả tiền thì mới được tắt, etc. Nhưng tạm thời thời mình sẽ list số ý chính như trên.)

Khi mình launch ads system này ra, mình biết mình thành công khi mình đạt được một số mục tiêu ban đầu:

• Ad được quy hoạch về một chỗ và đỡ rối hơn trước
• Ad có CTR tốt (CTR 2%)
• Ad vận hành được dễ dàng bởi team marketing và không cần kỹ năng technical, có thể edit trên CMS
• Kết quả của ads track được trên BI, giúp team marketing đánh giá hiệu quả dễ dàng

Có thể nói, dựa trên tiêu chí hiện trạng mục tiêu mình đã đề ra ban đầu, mình đã đạt được một số tiêu chí mình đặt ra ban đầu. Mình không gặp khó khăn khi đánh giá

Mình có thể thở phào nhẹ nhõm là mình đã own được cái "outcome" được cái feature này, chứ không chỉ own phần "delivery", chỉ ra được feature là đủ như lúc trước.

Nghe thì có vẻ khá mượt mà, nhưng khi ads này được launch ra được vài tháng thì mình nhận được complaint bên phía anh Head of Product là ads này quá khó chịu và gây distracted cho users. Việc complaint này hoàn toàn bình thường, vì tiêu chí của công ty hoàn toàn có thể thay đổi / bổ sung thêm theo thời gian.

Lúc đó mình có communicate lại những mục tiêu ban đầu thì anh có gợi ý mình một số hướng sửa, làm ads nhỏ lại, màu banner tối, chữ mute hơn, etc.

Thay đổi như sau, ad làm lại nhỏ hơn, chữ tối màu hơn, và ít nổi bật hơn:

Chuyện gì đến thì cũng đến, sau thay đổi thì CTR ads của bọn mình drop dữ dội, team cũng không happy vì điều này lắm.

Do đó mình mới initiate thêm 1 cái project ads improvement để cứu CTR của phần này, CTR sau đó được chỉnh lại để theo đuổi mục tiêu kép này:

• (1) Vừa phải dễ nhìn, không gây phiền users
• (2) Vừa phải dễ thấy - đủ visible, để users có thể nhấn vào (CTR ngon)

Sau khi thay đổi, cuối cùng như hiện tại thì ads trông như sau:

Sau đó dbdiagram ads trông dễ nhìn hơn do chữ đã to hơn và đậm hơn, và vì không được dùng màu nổi nữa nên mình phải dùng ảnh động để lấy chú ý từ users, nhờ đó CTR cũng cải thiện hơn trở lại.

Túm cái váy lại, mình nhận ra rằng điều tạo ra khác biệt không phải là mình build ads đẹp hay xấu, mà là mình đã mô tả được problem space đủ rõ để cả team hiểu hiện trạng, thống nhất mục tiêu và đánh giá được outcome, dù cho outcome đó có thay đổi theo thời gian.

Problem space bao gồm những tất cả những ràng buộc, hiện trạng, những tiêu chí, mục tiêu mà team đang theo đuổi. Khi problem space được đặt đúng, mình không chỉ “ship được feature”, mà còn own được kết quả của feature đó, và khi mục tiêu thay đổi, mình cũng biết phải điều chỉnh ở đâu và vì sao.

Problem Space cần khai thác được chiều sâu của vấn đề

Trong phần này mình xin lấy một trong những feature kinh điểm product nào cũng sẽ phải làm 1 lần, đó chính là trang onboarding :)))

Tất cả những product nặng technical nào mà có nhiều khái niệm, nhiều bước, thì chắc chắn sẽ bị users than phiền và điều đầu tiên team nghĩ đến là build 1 trang onboarding để hướng dẫn.

Cũng tình cờ là dạo gần đây mình qua công ty mới làm và cũng được giao build trang Onboarding này cho trang Business Portal của Ví thanh toán và Dịch vụ gửi tin nhắn của công ty.

Tuy nhiên ở task mình được giao ở Solution space luôn, tức là phải build 1 trang onboarding, no more no less. Vấn đề lúc đó là mình không thật sự biết phải ​build trang onboarding như thế nào vì mình mới vào, không rõ Business Portal hiện tại khó dùng cụ thể là chỗ nào là khó dùng như thế nào và build cái gì.

Mình biết Business Portal khó dùng thật, nhưng cụ thể mình cũng không rõ nó được kỳ vọng giải quyết vấn đề gì. Và quan trọng nhất là mình không biết thế nào thì được coi là một trang onboarding “tốt” trong bối cảnh của Ví điện tử / Dịch vụ gửi tin.

Nếu làm theo thói quen cũ thì cũng không khó: Mình hoàn toàn có thể thiết kế vài màn hình giới thiệu, viết thêm vài dòng hướng dẫn cho user, ship feature rồi coi như hoàn thành task được giao.

Nhưng càng nghĩ, mình càng thấy không yên tâm. Vì nếu mình không hiểu rõ problem ngay từ đầu, thì rất khó để trả lời những câu hỏi rất căn bản: build xong như vậy đã đúng chưa, có thật sự giúp được user không, hay cuối cùng cũng chỉ là một trang onboarding được làm ra… cho có.

Không phải vì mình không biết design hay không biết làm feature, mà vì:

• Mình không rõ vì sao cần build trang onboarding này
• Không biết onboarding này được kỳ vọng giải quyết vấn đề gì
• Và cũng không biết build xong thì đánh giá thành công ra sao

Đi tìm vấn đề trước khi build

Vì lúc đó mình thật sự không biết phải build onboarding như thế nào, nên mình quyết định chưa vội làm gì cả. Thay vào đó, mình quay lại hỏi một câu rất căn bản:

“User đang gặp vấn đề gì khi bắt đầu sử dụng Ví / Dịch vụ Gửi tin?”

Thế là mình bắt đầu đi collect dữ liệu. Không phải bằng một nghiên cứu hoành tráng gì, mà là đọc lại tất cả những gì mình có trong tay: feedback từ survey, ticket support, những câu hỏi user hỏi đi hỏi lại, rồi cả những đoạn trao đổi rải rác giữa team và khách hàng.

Khi bắt đầu gom các feedback lại với nhau, mình thấy phần lớn vấn đề đều xuất hiện ở những bước đầu tiên, khi user mới tiếp cận.

User bị kẹt không phải vì UI quá phức tạp, mà vì họ không hiểu các khái niệm nền tảng. Ví dụ như:

• Không hiểu mối quan hệ giữa Ví, Account và App
• Không hiểu Template là gì, tạo ra để làm gì
• Không hiểu Khái niệm Template Tag dùng để làm gì và ảnh hưởng ra sao
• Không hiểu vì sao Template có lúc được duyệt, có lúc lại bị reject

Khi không hiểu những thứ này, user rất dễ rơi vào một trạng thái khá tệ: họ vẫn làm theo hướng dẫn, nhưng không chắc mình đang làm đúng. Gặp lỗi thì cũng không biết lỗi nằm ở đâu, và cuối cùng là không biết nên hỏi ai để được giải thích cho rõ ràng.

Lúc đó mình bắt đầu nhận ra rằng vấn đề cốt lõi của onboarding không phải là thiếu hướng dẫn, mà là user chưa hiểu được các khái niệm nền tảng ngay từ đầu.

Định nghĩa lại thế nào là “user hiểu”

Từ đây, mình tự hỏi một câu khá quan trọng:

“Vậy rốt cuộc, thế nào thì được gọi là user đã hiểu?”

Với Ví / Dịch vụ gửi tin, mình nhận ra rằng user không cần nhớ định nghĩa, cũng không cần hiểu toàn bộ hệ thống ngay từ đầu. Thứ họ cần là làm được những việc cốt lõi.

Từ đó, mục tiêu onboarding bắt đầu rõ ràng hơn. User chỉ có thể được coi là “đã hiểu ở mức cơ bản” khi họ tự tay:

• Kết nối được App
• Liên kết được Account
• Tạo được Template đầu tiên
• Và gửi được tin đầu tiên

Nếu user làm được những việc này, thì dù họ chưa hiểu hết mọi khái niệm, mình vẫn có thể tin rằng họ đã hiểu đủ để sử dụng hệ thống.

Khi đã định nghĩa được như vậy, mình quay lại nhìn “trang onboarding” với một góc nhìn hoàn toàn khác. Câu hỏi không còn là “trang này cần giải thích những khái niệm gì?”, mà trở thành “trang này cần giúp user làm được bước nào tiếp theo?”.

Từ đây, onboarding không còn là một trang giới thiệu đơn thuần, cũng không phải là nơi gom tài liệu cho đủ. Nó trở thành một phần của hành trình học và activation của user, nơi mỗi bước đều gắn với một hành động cụ thể.

Cũng từ cách nghĩ đó, mình không chỉ build trang onboarding, mà còn:

• Thiết kế thêm nhiệm vụ tân thủ, để user biết mình đang ở đâu và cần làm gì tiếp theo
• Bổ sung nút customer support theo ngữ cảnh, để khi user bị kẹt, họ biết ngay phải tìm hỗ trợ ở đâu, thay vì tự mò mẫm

Và cũng từ thời điểm đó, mình mới thật sự cảm thấy rằng mình đang build onboarding để giải quyết một vấn đề thật, chứ không chỉ hoàn thành một task được giao.

Dù feature vẫn chưa được launch vì đang làm, nhưng riêng việc đi đào sâu thêm customer requests đã giúp mình nhìn rõ hơn rất nhiều về không gian vấn đề ban đầu, user đang bị kẹt ở đâu, vì sao họ kẹt, và onboarding thật sự cần giải quyết điều gì. Khi nào feature này có kết quả cụ thể hơn, mình sẽ quay lại cập nhật và chia sẻ thêm với các bạn nhé ^^

Tổng kết

Nhìn lại hai câu chuyện trên — từ ads system cho dbdiagram đến onboarding của Ví / Dịch vụ Gửi tin nhắn — mình nhận ra rằng điều tạo ra khác biệt không nằm ở việc mình chọn solution nào, mà nằm ở mình đã hiểu và mô tả problem space sâu đến đâu.

Khi problem space được đặt đúng:

• Team hiểu rõ hiện trạng product đang ở đâu
• Mục tiêu được nói ra rõ ràng và có thể đánh giá
• Solution không bị khóa cứng, mà có thể điều chỉnh khi bối cảnh thay đổi

Một điểm quan trọng khác mà mình học được là vấn đề và mục tiêu không phải lúc nào cũng cố định. Theo thời gian, khi bối cảnh kinh doanh, ưu tiên của công ty hoặc hành vi của user thay đổi, mục tiêu ban đầu hoàn toàn có thể cần được điều chỉnh hoặc mở rộng thêm, do đó cần nắm rõ và duy trì những ràng buộc này theo thời gian.

Khi problem space đã được mô tả đủ rõ, việc thay đổi mục tiêu không làm team bị “lạc hướng”, mà ngược lại, giúp team biết chính xác mình cần điều chỉnh ở đâu và vì sao.

Ngược lại, khi problem space chưa rõ, việc build feature rất dễ rơi vào trạng thái “làm cho có”: ship được nhưng không biết có giải quyết được gì hay không.