Giới thiệu

Chuyện là sắp tới mình có vinh dự được chia sẻ tại UXVN Conference 2024 về chủ đề "Làm thế nào để Product Designers hợp tác với Product Managers tốt hơn?".

Mình có may mắn được làm Product Manager được một thời gian, cũng như được có cơ hội tiếp cận, làm bạn và trò chuyện với nhiều PMs ở các công ty khác nhau trong quá trình làm khóa học Breaking into Product Management. Vì vậy, mình nghĩ cách mình có thể tạo được giá trị đó là cung cấp góc nhìn từ phía "bên kia sườn đồi" về các vấn đề mà Designers gặp với PMs.

Mục tiêu của mình cho bài viết này:

• Giúp Designers có thấu cảm hơn với Product Managers
• Giúp Designers frame được một vài vấn đề lớn của Product Managers.
• Giúp Designers giúp Product Managers làm việc tốt hơn. Mình sẽ đề cập một số cách mà mình thấy hiệu quả, nhưng mình sẽ dành nhiều thời gian nhất cho hai items trên.

Thấu cảm (empathize) là bước đầu tiên trong design thinking process để giải quyết vấn đề, sau đó là định nghĩa được vấn đề (define). Mình tin rằng sau khi có được thấu cảm và định nghĩa được vấn đề, các bạn Designers có thể nghĩ ra (ideate) những giải pháp sáng tạo hơn mình rất nhiều, và thử nghiệm chúng (prototype) trong ngữ cảnh thực tế để xem cái gì phù hợp.

PMs thường làm gì khiến Designers ngứa ngáy?

Tuy mình không trực tiếp có trải nghiệm đau thương với các bạn Designers, để tạo ra giá trị cho bất kỳ ai thì chúng ta đều phải có sự thấu cảm dành cho họ - đó là điều căn cơ nhất khi làm sản phẩm. Vì bài viết này cũng là một hình thái sản phẩm, nên chúng ta vẫn phải bắt đầu với Designers.

Mình đã nhờ một người bạn làm Product Design của mình với mối quan hệ rộng rãi đi khảo sát giùm các vấn đề của Designers khi làm việc với PM (cám ơn chị N. và tất cả những bạn đã cho mình inputs 🙏).

Sau đó mình đã tiến hành phân tích những dữ liệu thu thập được, bẻ các input từ Designers ra thành những trích đoạn nhỏ. Những điểm dữ liệu này được gán nhãn, phân loại và tổng hợp thành những cụm vấn đề lớn hơn.

PMs thiếu sự rõ ràng khi làm việc với Designers

Hãy điểm qua một số trích đoạn từ các bạn Designers, để chúng ta hình dung rõ hơn về vấn đề mà các bạn gặp. Sự thiếu thông tin có thể diễn ra một cách rất cụ thể, như việc viết PMs tickets thiếu thông tin:

Thêm 1 kiểu nữa là thiếu thông tin, giống như viết ticket mà mỗi cái title ấy, thì kiểu này cũng rất chán. Nó làm mình phải chủ động luôn cái phần mà đáng lẻ ra nó ko phải là việc của mình => mất thời gian vào những việc ko đáng. Rồi sau đấy mình ship design xong thì lại bảo thiếu này thiếu kia.

Sự thiếu rõ ràng còn đến từ việc PMs không biết cách truyền đạt kỳ vọng của họ về sản phẩm:

Bên em làm việc hay bị suffer với PM/PO là vì bên này PO/PM họ của client, thuần biz, họ nắm rất rõ process biz nhưng không nắm nhiều về cách build 1 sản phẩm digital như nào cho chuẩn. I mean mỗi tính năng lại có 1 PM/PO riêng nữa, nên việc không align ở mức độ cho phép của system rất khó, đa số lạc quẻ k à 🥲 ... Struggling lớn nhất khi làm với PM (non-tech) là việc đoán được expectation của họ và trao đổi để deal được giai đoạn MVP đầu rất khó huhu

Nếu chúng ta không hiểu cấu trúc của một sản phẩm phần mềm, thì rất khó để có thể miêu tả được chính xác thứ chúng ta đang hình dung trong đầu. Mình thấy hiện tượng này xảy ra rất nhiều ở những bạn PM có business background nhưng chưa trang bị cho mình những kiến thức về không gian giải pháp của sản phẩm.

PMs áp đặt quyết định lên Designers

Ngoài việc thiếu sự rõ ràng, PMs còn áp đặt quyết định lên Designers. Sau đây là một data point làm mình rất buồn cười 😆 . Cái này muốn chế ra cũng không được.

- PM phủ quyết design của PD vì ko làm theo mong muốn của người quyết định ký contract.

+ View PM: chiều theo ý khách để họ ký contract

+View PD: làm Design System, Design Pattern đủ cả rồi h nghe feedback design đòi làm theo ý khách, mà chắc méo j ng ta đã ký :)))

- PM xử lý ko khéo, dùng power để phủ quyết: PM chịu trách nhiệm cho sản phẩm nên có quyền quyết định design.

- PD cũng máo choá: thuê tao về đây để làm gì?

- Có dàn xếp sau đó nhưng cả 2 bên đều feel less secure rồi. Sau đó PM chọn trao đổi vs PD thông qua BA, tránh combat vs nhau -> thông tin PD muốn đào sâu để hiểu về problem space ko đầy đủ do bạn BA tập trung xử lý nghiệp vụ thôi

Điều mình thích ở data point này, đó là nó không chỉ có ngữ cảnh của sự mâu thuẫn, mà còn thể hiện được ảnh hưởng của nó lên mối quan hệ giữa Product Manager và Designer.

Có vẻ như đây là một chủ đề nhiều cảm xúc, vì chúng ta có thể cảm nhận rõ trong câu từ của các bạn Designers một sự bất mãn. Các bạn còn cho mình những ví dụ rất cụ thể (có cả mockup nữa luôn 🤣 nhưng chắc mình xin phép không show lên)

Giả sử Designer thiết kế ra A và B.

Designer chọn A. PM/PO/BA chọn B.



TH1:PM/PO/BA chọn bản B vì bảo hệ thống backend các thứ hiện chưa đáp ứng/xử lý được -> Designer cũng cần hiểu và đồng ý -> chốt chọn bản B.



TH2: Giả sử hệ thống BE đã đáp ứng. PM/PO/BA chọn bản B vì cho rằng bản B trông oke hơn, phân định rõ ràng email và phone hoặc đại khái 7769 lý do gì đó. Designer chọn bản A vì cho rằng làm thế người dùng không cần phải bấm chọn email or phone mà chỉ cần nhập giá trị vào còn lại hệ thống tự nhận diện xem nó là email hay phone thì sẽ giảm thiểu bước cho người dùng.



Nếu mọi thứ rơi vào TH1 thì quá dễ cho các bên và nó cũng logic. Nhưng rơi vào TH2 thì cuộc tranh luận kéo dài cho đến khi người nào có quyền to hơn thì nghe theo người đó vì ai cũng có lý của mình và chưa có cái gì chứng minh ý đó là đúng hay sai.


Đó là một số data points về Designers cảm thấy ngứa ngáy khi PMs áp đặt quyết định của họ quá nhiều.

Tại sao PMs lại làm những thứ khiến Designers ngứa ngáy?

Phải chăng có một hội đồng PMs họp kín với nhau hàng tuần để ngồi bàn luận ra những cách thức sáng tạo khiến cho cuộc sống Designers khổ sở hơn? Mình thì mình nghĩ 99% là không, hoặc nếu có thì cái hội đồng này đã không mời mình đến họp 🤣.

Đây là lúc mình có thể cung cấp những góc nhìn từ phía Product Managers cho mọi người.

Tại sao PMs lại áp đặt quyết định?

PMs và da thịt trong cuộc chơi (skin in the game)

Mình xin phép kể một câu chuyện làm sản phẩm của bản thân.

Mình đã có may mắn được dẫn dắt một sản phẩm từ 0-1, từ lúc chưa có gì cho đến lúc nó đã có người dùng và doanh thu. Nhiều ý kiến cho rằng giai đoạn khó khăn nhất trong việc làm sản phẩm là ở khâu đưa sản phẩm tiếp cận đến đúng thị trường có nhu cầu. Tuy nhiên, giai đoạn làm mình mất ăn mất ngủ lại diễn ra sau khi sản phẩm đã được người dùng đón nhận rồi.

Câu chuyện này diễn ra sau khi sản phẩm đã được tiếp cận được thị trường, đã có người dùng và doanh thu. Tuy nhiên, số lượng người sử dụng sản phẩm vẫn chưa cao như cách công ty đã kỳ vọng. Điều này dẫn đến áp lực xuất phát từ tầng cao nhất công ty. CEO áp lực xuống sếp mình, và sếp mình áp lực lên mình.

Áp lực như cụ thể thế nào?

• Sếp luôn hỏi mình cập nhật tiến độ của tuần đó, mặc dù trong buổi họp của cả team product mình đã cập nhật rồi.
• Sếp mình thường xuyên gián đoạn lúc mình đang nói để lái cuộc nói chuyện theo hướng khác.
• Sếp tập trung vào việc sản phẩm của mình đang không được như kỳ vọng như thế nào, và không có một nhận xét cụ thể nào về cách mình đang làm, cũng như đề xuất các hướng đi để làm tốt hơn.
• Ngoài những buổi họp 1-1, sếp mình cũng rất sẵn sàng công khai chỉ trích cũng như tạo áp lực cho mình trong những buổi họp của team Product.

Đỉnh điểm của câu chuyện này đó là khi sếp "đi sau lưng" mình và đặt KPI cho quý sau phải tăng gấp đôi số lượng người dùng. Bình thường theo quy trình của công ty lúc đó thì mỗi PM sẽ tự dựa vào số liệu lịch sử để đề ra mục tiêu cho quý sau, thường cố gắng tăng tầm 15% so với mức tăng trưởng tự nhiên. Nhưng vào lúc đó, sếp mình đã tự áp đặt KPI lên mà không thông qua ý kiến của mình, cũng không cho mình biết trước. Mình chỉ vô tình biết đến đó vì có thói quen hay đi dạo các dashboard ở trong công ty và tình cờ thấy được team mình có commitment đó cho quý sau.

Thời điểm đó, công ty mình tính toán performance bonus dựa vào KPI của product team, nên lúc đấy áp lực mà mình cảm thấy không chỉ đến từ trách nhiệm với sản phẩm, mà còn là trách nhiệm với team của mình. Nếu team mình quý này nếu không đạt được KPI và không nhận được bonus, thì điều đó sẽ ảnh hưởng như thế nào đến động lực làm việc ở quý sau của họ?

Mình xin phép tạm ngưng câu chuyện ở đây trước khi kể tiếp, để nói về một ý niệm mà mình muốn truyền tải, mà mình nghĩ mọi người cũng biết về mặt lý thuyết nhưng đôi khi chưa thấu cảm sâu được:

Để chúng ta tự kiểm chứng được là mình có da thịt trong cuộc chơi làm sản phẩm hay không, thì mọi người có thể tự hỏi bản thân câu hỏi này:

"Hãy nhớ về lần gần nhất mà bạn bị đem ra truy cứu trách nhiệm khi sản phẩm không được như mong đợi"

Nếu bạn có thể nhớ lại được trải nghiệm đó một cách rõ ràng, thì chắc hẳn bạn đã có nhiều da thịt trong cuộc chơi làm sản phẩm.

Đây là một thực trạng mình thấy rất phổ biến đối với rất nhiều PMs, không chỉ đối với riêng mình. Dù bạn là PM hay PO trong các công ty Product hay Outsource, thì khả năng cao bạn là người chịu trách nhiệm chính với sự thành bại của sản phẩm.

Khi trong tình huống có nhiều rủi ro, chúng ta sẽ tự nhiên muốn tìm kiếm sự điều khiển

Câu chuyện không chỉ kết thúc ở đó. Bật mí một chút là câu chuyện này có một kết thúc có hậu (đối với mình). Khi bị sếp áp lực về việc số lượng người sử dụng sản phẩm đang không như kỳ vọng như vậy, thì mình đã vượt qua điều đó như thế nào?

Việc đầu tiên mình làm là tổng hợp lại các dữ liệu chi tiết hơn về acquisition, activation và retention. Nghe khá là hiển nhiên, nhưng lúc đó công ty có tầm 5 team sản phẩm, mà chỉ có mỗi một bạn làm dữ liệu chuyên sâu cho toàn bộ các sản phẩm. Không chỉ riêng mình mà còn nhiều team product khác cũng có nhu cầu về số liệu đang chờ bạn giải quyết, và thời gian trung bình cho đến khi nhận được một báo cáo hoàn chỉnh là tầm một tháng.

May mắn là bản thân mình cũng có background kỹ thuật, nên mình vẫn có thể truy cập trực tiếp vào cơ sở dữ liệu của sản phẩm để tự trả lời câu hỏi. Nhưng việc này cũng khiến mình tốn một vài tuần.

• Dữ liệu trong thực tế thường không được sạch sẽ - tức là có những dòng dữ liệu bị lỗi, và sẽ có những dữ liệu mà mình tưởng nằm cùng một chỗ nhưng bị phân mảng do lý do kỹ thuật.
• Nếu bạn đã từng làm việc với cơ sở dữ liệu hay viết SQL, thì bạn cũng biết rằng việc viết ra được logic truy vấn dữ liệu mà có độ chính xác và tin cậy cao không hề dễ dàng. Việc ra được kết quả thì dễ, nhưng để đảm bảo kết quả đó đúng thì chúng ta cần phải đối chiếu theo nhiều cách khác nhau. Đưa ra quyết định dựa trên số liệu không chính xác thì nó giống như là bịt mắt lái xe vậy - đến Vin Diesel cũng không làm được (có khi Fast & Furious phần sau lại có phân cảnh này 😆).

Nhưng vì áp lực quá lớn, nên mình đã phải thức đêm thức khuya để cố gắng tự chạy ra số liệu cho chính xác. Khi nhìn vào số liệu, thì mình thấy được bottleneck của sản phẩm nằm ở activation - chỉ tầm 15%. Mình sẽ không đi chi tiết cách mình định nghĩa Activation lúc đó là gì, nhưng nhìn chung vấn đề lúc đó là chưa nhiều người sử dụng một tính năng quan trọng trong sản phẩm mà giúp cho họ nhận ra được giá trị của sản phẩm. Mình biết điều này là bởi vì trong số những người có xài tính năng đó, thì phần trăm họ quay trở lại sử dụng tiếp rất cao, và khi phỏng vấn thì họ cũng nói rằng tính năng đó chính là thứ tạo ra giá trị.

Giả thuyết của mình lúc đó là: người ta không sử dụng tính năng này vì người ta không biết đến sự tồn tại của nó. Giả thuyết này đến từ việc platform của công ty mình có khá nhiều mô-đun và nhiều tính năng, dẫn đến việc người dùng phải đối mặt với nhiều thông tin, nên họ sẽ chỉ sử dụng những thứ được giới thiệu dễ hiểu và trực quan.

Vô tình lúc đó trong công ty có một project onboarding đang diễn ra, do một bạn PM khác dẫn dắt. Project đó sẽ làm lại luồng onboarding cho toàn bộ platform để hướng dẫn người dùng sử dụng một số tính năng tạo ra nhiều giá trị.

Vấn đề ở đây là khi mình đọc qua về tài liệu của dự án đó, thì trong luồng onboarding đó lại không có tính năng của sản phẩm mình. Điều này cũng dễ hiểu, vì sản phẩm của mình chỉ vừa mới tung ra thị trường, nên nó chưa được xuất hiện nhiều trong các cuộc thảo luận của những team khác.

Mình muốn đưa tính năng của sản phẩm mình vào trong luồng onboarding mới đó. Mình có niềm tin rằng: nếu người dùng biết đến tính năng này, và được hướng dẫn về giá trị của nó trong platform, thì sẽ nhiều người sử dụng sản phẩm của mình hơn.

Mình đã nói với sếp mình rằng: "nếu anh muốn em tăng số lượng người dùng cho sản phẩm, thì em cần được tham gia vào dự án onboarding đó." Sếp mình đã đồng ý cho mình tham gia, nhưng với một điều kiện: mình và bạn PM kia sẽ cũng nhau phụ trách dự án, kiểu như là co-lead. Mình cũng không chắc co-lead nghĩa là gì, nhưng mình đoán sếp vẫn muốn cho bạn PM kia nắm quyền điều khiển. Nhưng với mình thì bước đầu tiên là phải tham gia được vào dự án đó.

Tại sao lại phải tham gia cho được, bởi vì mình biết bạn PM đó thì còn khá là trẻ và chưa có nhiều kinh nghiệm dẫn dắt, nên trong những cuộc bàn luận, thì ý kiến và quan điểm của mình dường như luôn có sức nặng hơn đối với stakeholders. Một phần là vì mình có kinh nghiệm hơn, một phần là mình xây dựng mối quan hệ tốt, và phần còn lại là lúc đó mình quyết tâm phải đạt được mục đích cho bằng được.

Nói cao cả thì là vì trách nhiệm của mình với sản phẩm và với performance bonus của team, còn ở khía cạnh trần trụi hơn thì mình muốn chứng minh cho sếp mình rằng, đây không phải là kết thúc của mình. Bằng cách chuẩn bị rất nhiều trước các buổi họp để đưa ra lập luận chắc chắn, cộng với quyền lực mềm đã có sẵn, thì mình đã đạt được mục đích và đưa tính năng vào luồng onboarding thành công.

Kết quả: activation của sản phẩm mình tăng gần gấp đôi, monthly active users cũng tăng gần gấp ba lần, và retention thì không bị ảnh hưởng nặng.

Kể từ đó, mình không còn bị sếp áp lực nữa, cũng như có thêm được một "chiến tích" để kể lại lúc đi phỏng vấn hay để vào CV. Và đó là kết thúc câu chuyện này, một kết thúc có hậu, ít nhất đối với mình.

Trong câu chuyện trên, mình đã may mắn xác định được điểm đòn bẩy - nơi mà khi chúng ta tác động sẽ mang lại kết quả lớn nhất. Điểm đòn bẩy trong câu chuyện này chính là project onboarding do bạn PM kia dẫn dắt. Mình đã có niềm tin là nếu đưa được tính năng vào trong luồng onboarding thì nó sẽ giải quyết được bottleneck hiện tại. Với niềm tin đó, mình đã làm mọi thứ trong khả năng và phạm vi đạo đức để làm cho nó xảy ra.

Nhưng việc tìm ra được điểm đòn bẩy không hề dễ dàng. Chúng ta có thể tưởng tượng được câu chuyện trên đã có thể diễn ra hoàn toàn khác, nếu như thay vì mình chọn tham gia project onboarding, thì mình lại nghĩ ra các tính năng mới để làm thêm. Dưới áp lực thời gian, khả năng cao mình cũng sẽ áp đặt lên các bạn Designers, bảo rằng các bạn phải làm những tính năng này mà không thật sự đưa được luận cứ rõ ràng về vấn đề nó giải quyết.

Bởi vì việc tìm ra "điểm đòn bẫy" khá là khó và bất định, nên PMs nhiều lúc lại chọn điều khiển những thứ cụ thể hơn (nhưng chưa chắc đã có kết quả tốt nhất): khía cạnh thẩm mỹ, userflow hay là cái nút này nên đặt ở đâu.

Khi PMs cố gắng điều khiển những khía cạnh như vậy, thì Designers cảm thấy rất khó chịu. Các bạn sẽ tự hỏi bản thân là, ủa vậy công ty tuyển các bạn vào để làm gì?. Chưa kể rằng các bạn Designers có chuyên môn mạnh hơn PMs rất nhiều ở những khía cạnh Design, nên dù PMs muốn sự điều khiển đi nữa thì khả năng cao cũng không phải là phương án tối ưu.

Tại sao PMs lại thiếu sự rõ ràng?

Thiếu rõ ràng thường là trạng thái mặc định

Hãy nghĩ về lần gần nhất mà bạn làm một task gì đó, làm thế nào để bạn đã biết được mình cần phải làm gì, tới đâu là đủ, và output của mình sẽ được sử dụng như thế nào? Nếu bạn là Designers, thì khả năng cao những inputs đó sẽ đến từ PMs của bạn, nhưng nếu vậy thì PMs của bạn lấy inputs đó từ đâu?

Inputs đó thường đến từ việc nghiên cứu thị trường, phản hồi người dùng, ý kiến lãnh đạo các phòng ban, từ lãnh đạo của công ty, và đôi khi là từ một bạn business trong công ty mà rất aggressive, hay lớn tiếng và luôn muốn PMs làm gì cũng phải làm liền (chắc mỗi công ty đều có ít nhất một bạn như vậy 🤪).

Những luồng thông tin hiếm khi nào đến cùng một lúc, mà chúng thường rải rác ngày này qua tháng nọ, mỗi lần lắt nhắt một ít. Có thể sếp bạn nói bâng quơ về một ý tưởng tính năng gì đó trong một buổi chiều thứ sáu, rồi hai tuần sau thì sếp bạn lại hỏi là tại sao chưa làm cái đó. Có tháng mãi mà không thấy người dùng nào feedback hay phàn nàn gì. Có hôm thì khách hàng nhắn tin cho bạn vào sáng thứ bảy về một vấn đề mà họ cho rằng là rất critical.

Sự thiếu rõ ràng thường là trạng thái mặc định khi làm sản phẩm.

"Requirement" không tự sinh ra hoặc được ai đó đưa cho PMs, mà thứ chúng ta nhận được chỉ là rất rất nhiều thông tin, góc nhìn và ý kiến bảo rằng chúng ta nên làm gì. Nếu bạn đã từng phải ngồi xuống định hình "requirement" cho sản phẩm phần mềm từ danh sách 100 inputs của sales, customers, CEO, thì bạn sẽ thấy rằng nó không hề rõ ràng hay hiển nhiên một chút nào.

Sự rõ ràng khó để đạt được vì làm sản phẩm rất phức tạp. Để hiểu thêm về sự phức tạp này, chúng ta hãy thử bóc tách sự rõ ràng khỏi sự cụ thể.

Rõ ràng khác với cụ thể

Có một nghịch lý như thế này: Designers không thích khi PMs không đưa đủ thông tin để làm việc, nhưng họ cũng không thích khi PMs áp đặt quá nhiều thông tin về Design, vậy vấn đề ở đây có phải là về mật độ thông tin không?

Mình đã mentor rất nhiều bạn Junior PMs giải quyết một số đề bài mà các nhà tuyển dụng thường dùng trong quy trình phỏng vấn. Một trong những pattern thường gặp, đó là các bạn Junior PMs thường rất hay nhảy vào chi tiết cụ thể của giải pháp. Giải pháp sẽ có tính năng gì, trong tính năng đó thì nó sẽ có những chi tiết cụ thể gì, hay sẽ hiển thị lên màn hình như thế nào. Các bạn có thể nghĩ ra rất nhiều thông tin cụ thể về giải pháp.

Vậy có phải các bạn Designers sẽ thích làm việc với Junior PMs hơn không? Theo kinh nghiệm của mình là không. Các bạn Junior PMs thường sẽ là người áp đặt về giao diện hay đi quá sâu vào chi tiết của trải nghiệm người dùng, vì đó là thứ duy nhất mà các bạn nghĩ ra. Nếu giao hết cho Designers rồi thì các bạn sẽ tạo giá trị ở chỗ nào?

Khi mentor những bạn Junior PMs như vậy, thì mình thường giúp các bạn khoan nghĩ về giải pháp, mà nên tập trung xác định được những dữ kiện quan trọng cốt lõi của bài toán.

• Đối tượng người dùng trong đề bài là ai, vấn đề của họ là gì, khi nào họ gặp vấn đề đó, vấn đề đó ảnh hưởng gì lên công việc hay cuộc sống của họ.
• Người dùng tương tác với những nhân vật khác trong đề bài như thế nào, và có những ràng buộc gì trong những tương tác đó hay không. Trong ngữ cảnh B2B thì ít khi nào người dùng sản phẩm một mình, mà họ luôn phải tương tác với những nhân viên khác và khách hàng để hoàn thành được công việc của họ.
• Sản phẩm hiện tại của công ty đang giải quyết vấn đề gì, và theo cách nào. Một số công ty có value proposition là compliance thì cúng ta không thể làm tính năng mới mà không suy nghĩ đến ràng buộc compliance được.

Khi các bạn Junior PMs kết nối được các dữ kiện quan trọng trong bài toán, thì các bạn có thể đưa ra được những product hay feature concept tương đối rõ ràng, mà chưa cần quá cụ thể về hình thái nó sẽ thể hiện như thế nào trên giao diện. Chúng ta có thể đạt được sự rõ ràng trong suy nghĩ mà không cần quá nhiều thông tin.

Vì sự "Rõ ràng" và "Cụ thể" là hai chiều không gian độc lập nhau, ta có thể vẽ lên một ma trận như trên:

• A bad solution: đây là điều mà các bạn PMs thiếu kinh nghiệm thường làm. Ở khu vực này, các bạn có thể nghĩ ra được rất nhiều chi tiết cụ thể, nhưng sẽ khó trả lời rõ ràng được việc nó liên kết như thế nào với các ràng buộc của bài toán.
• A high-level problem statement: các bạn Senior hơn sẽ có khả năng định hình vấn đề bao gồm những ràng buộc tiên quyết của bài toán. Đây cũng là khu bực lý tưởng để PM trao quyền cho Designers. Với một problem statement rõ ràng, Designers có thể đóng vai trò như người đồng hành cùng giải quyết vấn đề với PMs.
• A low-level solution: Có một số tình huống mà PMs sẽ rơi vào khu vực này, ví dụ như khi đội ngũ development team chưa có độ trưởng thành trong Product mindset cao, hoặc khi bị thiếu nhân lực về Designers hoặc Dev. Nếu team bạn có đầy đủ nhân lực và họ sẵn sàng cùng bạn giải quyết vấn đề, thì vùng đất này sẽ tương đối micromanagement.
• A blank slate: Khi chúng ta không có sự rõ ràng và cũng đang không thể nghĩ ra được giải pháp gì cụ thể, chúng ta sẽ không làm gì cả.

Quay trở lại nghịch lý trên: Designers không thích khi PMs không đưa đủ thông tin để làm việc, nhưng họ cũng không thích khi Designers áp đặt quá nhiều thông tin không cần thiết. Khi chúng ta phân tách giữa khái niệm "Rõ ràng" và "Cụ thể", thì có thể reframe lại như sau: Designers cần một bài toán được định hình rõ ràng từ PMs hơn là những chi tiết cụ thể về giải pháp mà PMs muốn.

Khi chưa xác định được các yếu tố tiên quyết và quan trọng trong bài toán, thì chúng ta sẽ không biết phải làm gì. Trạng thái mặc định khi không biết làm gì sẽ là ... không làm gì, hay nói cách khác là không cung cấp thông tin gì cả. PMs không ghi thông tin gì trong tickets vì họ một cách vô thức mong muốn Designers hoặc Developers giúp họ suy nghĩ về những chi tiết đấy. Tuy nhiên việc nghĩ ra các giải pháp cụ thể mà chưa có được sự rõ ràng thường phản tác dụng.

Làm thế nào để Designers giúp PMs làm công việc của họ tốt hơn?

Chuyển dịch góc nhìn từ "Đó là việc của họ!" sang "Việc của chúng ta là tạo ra giá trị"

Trước khi đi vào những giải pháp cụ thể, thì chúng ta cần sự rõ ràng trong mindset: PMs hay Designers thì đều có cùng một mục tiêu, đó là tạo ra giá trị cho người dùng và doanh nghiệp.

Vai trò của chúng ta có thể khác nhau, nhưng chúng ta không thể thiếu sự hợp tác và giúp đỡ lẫn nhau để có thể tạo ra giá trị Vì vậy, thay vì chúng ta nghĩ rằng "Đó là việc của họ", thì chúng ta nên frame góc nhìn thành "Làm thế nào chúng ta để giúp PMs tạo ra được giá trị một cách tốt hơn?"

Sau đây là hai cách mình thấy khá là hiệu quả. Khi Designers làm những điều sau thì mình cảm thấy công việc của mình rất dễ dàng và suôn sẻ. Tuy nhiên nó chỉ là hai trong nhiều giải pháp. Hy vọng với hai problem statements ở trên thì mọi người có thể tự đối chiếu xem nó có liên quan trong tình cảnh của mình không, và nếu có thì mình sẽ giúp PM như thế nào.

Thu thập và cung cấp insights ngay cả khi PM của bạn không hỏi

Thường khi chúng ta cần insights thì lúc đó đồng hồ đã bắt đầu đếm ngược đến deadline. Dưới áp lực thời gian thì việc nghiên cứu hay tìm kiếm insights bắt đầu bị đem ra mổ xẻ là có cần không và cần đến mức nào. Hơn nữa, nhiều lúc khi cần insights từ người dùng thì lại không có một quy trình hoặc cơ sở hạ tầng gì để giúp chúng ta tiếp cận và mời được người dùng phỏng vấn. Chính vì vậy, hãy chủ động tạo thói quen thu thập insights một cách thường xuyên, để rèn luyện cơ bắp này không phải chỉ cho bạn mà còn cho cả team.

Đừng chỉ cung cấp thông tin. Điều đó chỉ thêm một luồng thông tin nữa mà PM phải xử lý, góp phần làm cho họ rối rắm hơn. Thay vào đó, hãy cung cấp góc nhìn của bạn về việc tại sao thông tin đó tồn tại, và nó có thể được sử dụng như thế nào với những thông tin khác như thế nào. Đừng chỉ bảo là "Đây là thứ Users nói hay đây là kết quả của Usability Testing", hãy nói thêm rằng "Tôi nghĩ Users nói như vậy là vì họ có vấn đề này, và với mục tiêu của công ty năm tiếp theo thì đây là một vấn đề đáng để giải quyết".

Đừng sử dụng dữ liệu để bảo vệ quan điểm của bạn. Mình muốn nói điểm này là vì đã nghe nhiều bạn Designers đi học thêm về các phương pháp định tính định lượng nhằm mục đích chứng minh rằng Design của mình đúng và PM nói vậy là sai. Chúng ta không nên biến nó thành cuộc tranh luận ai đúng ai sai, vì người có quyền lực nhiều hơn thường là người thắng. Khi họ đã cảm nhận được bạn đang đưa ra những bằng chứng này nhằm mục đích phòng tấn công họ, thì họ sẽ rất dễ dàng dùng quyền lực mềm để phủ quyết.

Thay vào đó, hãy dùng các dữ liệu định tính và định lượng để tạo ra những cuộc nói chuyện cởi mở nhằm mục đích tạo ra giá trị. Điều đó không hề dễ dàng, vì trong nhiều tình huống thì PMs vẫn bị chi phối bởi cái tôi. Nhưng nhìn về đường dài thì chỉ có việc nói chuyện cởi mở như thế mới có thể giúp cho mối quan hệ giữa PM và Designers trở nên tốt hơn. Điều đó đòi hỏi cả hai bên phải cùng cố gắng, nhưng các bạn Designers vẫn có thể chủ động gợi mở ra các cuộc nói chuyện như vậy.

Hỗ trợ PMs trong việc đánh giá trade-offs với low-fidelity prototypes để đạt được sự rõ ràng

Một lý do khác khiến PMs không rõ ràng khi giao việc cho Designers là họ chưa thực sự chắc mối liên hệ giữa các dữ kiện, ràng buộc và cơ hội tiềm năng chính xác là gì.

Thay vì chờ đợi PM đưa ra "requirement", bạn có thể chủ động nói chuyện để hiểu ngữ cảnh của họ, và đề nghị tạo ra các low-fidelity prototypes. Họ đôi khi sẽ e sợ là nói ra nhiều ngữ cảnh nhưng chưa hệ thống hóa lại sẽ làm cho bạn rối theo. Nhưng bạn cần phải tìm cách giúp họ vượt qua nỗi sợ này, cũng như chuẩn bị tinh thần để góp phần hệ thống hóa rất nhiều thông tin. Khi bạn tạo ra được sự an toàn về tâm lý cho PM, dù chưa có thứ gì chắc chắn như "requirement" nhưng họ sẽ cho bạn sẽ tiến gần hơn với những luồng thông tin đang hiện hữu.

Các bản phác thảo đơn giản hoặc wireframe sơ bộ sẽ giúp PM nhìn thấy tổng quan vấn đề, hiểu rõ hơn về cách các ràng buộc liên quan và ảnh hưởng lẫn nhau, mà không bị “kẹt” trong những chi tiết giao diện quá sớm. Mình nghĩ wireframe nó đã được sử dụng khi viết "requirement" quá nhiều đến nỗi, dường như có cảm giác nó là thứ gì đó làm ra để biến thành commitment. Vì vậy mà mình thích framing prototype hơn, vì khái niệm mẫu thử đầu tiên sẽ cho phép chúng ta dễ dàng bỏ nó đi.

Một trong những chỉ dấu của các bạn senior PD/PM, đó là phân biệt được giữa "Rõ ràng" và "Cụ thể". Hơn nữa, khi prototype ở các giai đoạn còn sớm trong vòng đời tính năng hay sản phẩm, thì các bạn Senior PD sẽ thường sẽ tập trung vào feature concepts, bỏi vì thứ chúng ta cần tập trung là các concepts này sẽ giải quyết những ràng buộc nào của bài toán, và có những đánh đổi nào (feature concepts là gì thì chắc mình xin phép viết trong một bài viết khác)

Qua các prototypes đó, bạn và PM có thể cùng khám phá ràng buộc của vấn đề cũng như các sự đánh đổi trong giải pháp. Một điều quan trọng là Designers cần phải tham gia sớm và liên tục, để tránh trường hợp nước đến chân mới nhảy. Khi chúng ta bị áp lực lớn thì rất dễ để bám víu vào những thứ cụ thể mà hy sinh đi mất sự rõ ràng. Nếu bạn cùng PM prototype từ sớm, PM sẽ dần nhận biết rõ hình hài của bài toán, từ đó giảm bớt tình trạng áp đặt chi tiết hoặc không đủ thông tin, và giúp hai bên thống nhất hướng đi một cách hiệu quả hơn.

Kết luận

Product Design và Product Management là hai vai trò gắn chặt với nhau, cùng hướng đến mục tiêu tạo ra giá trị cho người dùng và doanh nghiệp. Qua việc thấu hiểu những áp lực, trách nhiệm mà PMs phải gánh vác (có “da thịt trong cuộc chơi”), cũng như việc phân biệt giữa “rõ ràng” và “cụ thể” trong việc truyền tải vấn đề, mình hy vọng các bạn Designers sẽ hiểu hơn về PMs.

Thay vì chỉ chờ đợi requirements rõ ràng, Designers có thể chủ động hỗ trợ PMs trong việc cung cấp insights thường xuyên để tìm ra những "điểm đòn bẩy", cũng như làm rõ vấn đề bằng low-fidelity prototypes. Việc thu thập và cung cấp cho PMs insights thường xuyên sẽ giúp cho bạn xây dựng niềm tin giữa hai bên. Từ đó, PMs sẽ dần giảm bớt nhu cầu áp đặt, sẵn sàng lắng nghe và hợp tác, và Designers cũng có được nguồn thông tin rõ ràng hơn để làm tốt công việc của mình.

Sự thấu cảm và tinh thần hợp tác chính là chìa khóa đến thành công. Khi cả hai bên hiểu rõ vai trò, áp lực, mục tiêu và cách tư duy của nhau, mối quan hệ sẽ trở nên bền vững, giúp tạo ra những sản phẩm chất lượng cao, vừa ý nghĩa cho người dùng vừa thành công về mặt kinh doanh.