Làm sản phẩm

1 team nói chung (không chỉ team làm sản phẩm) sẽ bao gồm đối ngoại và đối nội

  • Đối ngoại là làm sao cho những team khác, những phòng ban khác hiểu được giá trị công việc của team mình, thấy team mình ngon (looks good), từ đó hỗ trợ team mình tốt hơn

Khi làm việc với những phòng ban khác nhau sẽ không tránh khỏi căng thẳng, vai trò của leader là làm sao để giữ nó là những căng thẳng mang tính xây dựng (healthy tension) và cuối cùng là dung hòa những góc nhìn, phản hồi, ưu tiên, mục tiêu của các bên khác nhau vào 1 giải pháp chung có lợi nhất cho công ty và khách hàng. Đây là chỗ tạo ra giá trị lớn nhất của product leader.

Đó cũng là lí do mà 1 kĩ năng quan trọng khi làm Product là cần biết "nhảy nhiều điệu". Cần có sense về UX, về Tech (để lead team nội bộ) nhưng đồng thời phải hiểu có sense về cả Business (để cảm thông và nghĩ được phương án hỗ trợ công việc của user 1 cách tốt nhất).

Khi người làm Product hiểu được user, hiểu vì sao bộ phận này lại cứ push tính năng này (vì họ có áp lực này nè chứ không phải push chơi cho vui) thì họ có thể hoặc tư vấn user 1 cách giải quyết khác gọn hơn (giảm áp lực cho team mình) hoặc có thể đưa ra 1 giải pháp tổng quát hữu ích nhất có thể, làm cho user tin tưởng (anh này ảnh cũng hiểu mình đây chứ không phải chỉ biết code không). Từ đó những căng thẳng (friction) sẽ được giải quyết tốt hơn, vì 2 bên tin nhau.

Người làm Product còn có lợi thế hơn user của họ ở chỗ sẽ làm với nhiều user khác nhau, nên góc nhìn sẽ đa dạng hơn và khi thiết kế giải pháp sẽ tổng quát hơn. Ví dụ bộ phận Sales đưa ra yêu cầu tính năng có thể đẩy doanh số nhưng ảnh hưởng trải nghiệm khách hàng, người làm Product vì cũng có làm với bộ phận Chăm sóc khách hàng nên nhận ra vấn đề này, tư vấn cho cả 2 để ra 1 giải pháp dung hòa được quyền lợi cả 2 team. Khi đó, người làm Product giống như quân sư vậy :). Muốn được điều này, cần đảm bảo mình có thể nhìn vấn đề 1 cách tổng quát (overview)

1 cách khác cũng sẽ giúp giải quyết friction, đó là hướng về giá trị cốt lõi chung (core value) của công ty, như vậy câu chuyện sẽ không phải là team nào có lý hơn team nào, mà làm sao để cùng giải quyết vấn đề chung.

  • Đối nội là làm sao để xây dựng 1 team tốt và đảm bảo team có môi trường để thực hiện tốt công việc của mình.

A. Đảm bảo team có môi trường để thực hiện tốt công việc của mình sẽ có 3 phần: Làm sao để team hiểu cần làm gì ? Làm sao để team thoải mái làm ? Làm sao để đánh giá công việc team làm ?

Làm sao để team hiểu cần làm gì ?

Có 2 cách để giải thích công việc cho team:

  • giải thích chi tiết từng ý (phù hợp với team junior)

  • giải thích "vì sao" (the why) cần thực hiện việc này và hướng team có động lực tìm phương án giải quyết nó (the how). Cách thứ 2 về lâu dài sẽ tốt hơn vì

    • đỡ mất công người leader, manager làm và follow những việc quá chi tiết (từ đó họ sẽ có nhiều thời gian tập trung vào những vấn đề strategic hơn như xây dựng team, xác định roadmap chung)

    • đồng thời team cũng sẽ thích thú vì được "trao quyền" tham gia vào quá trình tìm tòi khám phá cách giải quyết vấn đề, đây là 1 trong những điểm thu hút người giỏi. Ngoài ra, phương án giải quyết cuối cùng có thể là tốt hơn những gì leader nghĩ ban đầu.

Dễ hình dung thì leader sẽ là enabler hơn là do-er. Lưu ý là "vì sao" sẽ có nhiều mức độ, những cái strategic (mục tiêu chung trong quí của team, của công ty) sẽ cần được nhắc đi nhắc lại và đảm bảo là các team cũng như các thành viên trong team hiểu được nó (đây là 1 qui trình khá quan trọng trong các công ti MNC và hay bị bỏ qua trong các team Product).

Làm sao để team thoải mái làm ?
Sau khi team hiểu được mục tiêu, môi trường tốt để team làm việc đó là khi họ được tin tưởng để tự chủ trong các công việc của mình (autonomy), đồng thời hiểu rằng mình có trách nhiệm (accountability) rõ ràng trong việc hoàn thành các công việc đó.

Trong quá trình làm, vai trò của manager là "đặt câu hỏi đúng" hơn là micro-manage (vẫn cần trong 1 số tình huống) và khuyến khích mọi thành viên cũng cùng đặt câu hỏi khi có vấn đề gì chưa rõ ràng, không ngại gì cả.

Làm sao để đánh giá công việc team làm ?
Kết quả của team cũng nên được định nghĩa rõ ràng và có các metric đánh giá được đo lường cũng như giải thích cho những người liên quan hiểu kết quả của họ là ảnh hưởng tới metric nào. Đồng thời team cần focus vào việc, vậy cuối cùng mình có giải quyết được vấn đề gì cho người dùng hay không (outcome) hơn là đã thực hiện những tính năng gì trong mấy ngày (output).

B. Xây dựng 1 team tốt

Người leader cần nhận ra đây là 1 trong những công việc quan trọng nhất của mình. Vì cái đánh giá họ bây giờ không chỉ là công việc của họ mà là kết quả của cả team tạo ra thế nào.

Có thể coi "team" (chứ không phải tính năng phần mềm) sẽ là product chính mà người làm leader cần xây dựng cho tốt :)

Người giỏi sẽ cảm thấy được trân trọng khi họ có thử thách thú vị (challenged), được ghi nhận khi hoàn tất nó (recognized) và được tôn trọng. Đồng thời cần hiểu rằng người giỏi sẽ rất không thích việc team có những thành viên "dưới chuẩn" và trách nhiệm của leader là cần giải quyết vấn đề này. Họ cần coi team như 1 đội bóng và luôn tìm cách có những cầu thủ tốt nhất hơn là coi team như 1 gia đình.


Những keyword quan trọng nhất cần nhớ khi làm Product là

A. Cân bằng (balance)

Cân bằng giữa việc có góc nhìn overview, nghĩ giải pháp lâu dài tổng thể (do the right things) và việc đảm bảo triển khai các vấn đề hàng ngày (do things right). Thường sẽ dễ bị cuốn vào cái này hoặc cái kia, cần luôn nhắc mình cần làm cả 2

Cân bằng request và quyền lợi của các user/phòng ban khác nhau vì người làm Product có nhiều thông tin nhất

Cân bằng request của user và khả năng đáp ứng của team

B. Tò mò (curiosity) và luôn đặt câu hỏi vì sao (the why), còn gì nữa, rồi sao nữa

Người làm Product cần luôn tò mò về những khó khăn người dùng đang gặp phải và về những giải pháp mình còn có thể đưa ra để giúp họ giải quyết vấn đề tốt hơn, đi đến tận cùng của những vấn đề đó.

Đây là 1 trong những cái giúp người làm Product đảm bảo sản phẩm strategic, giải quyết đúng vấn đề ảnh hưởng nhiều nhất và đem lại giá trị lớn nhất cho người dùng


Các phương châm làm sản phẩm chính

  • Nghĩ lớn nhưng bắt đầu thực tế. Nghĩ về mục tiêu lâu dài đồng thời không ngại trao đổi tới lui với user để đảm bảo mục tiêu triển khai ban đầu nằm trong deadline đã thống nhất

  • Dùng data. Lưu ý nên là data-informed, tức dùng data hỗ trợ quyết định của mình hơn là data-driven - coi insights từ data là quyết định cuối cùng

  • Triển khai để cải tiến (ship to learn). Tránh làm sản phẩm quá lâu trong khi nhận được phản hồi từ user quá ít

  • Gắn liền với các mục tiêu chung của user, phòng ban, công ty


Đặc điểm của những team làm Product tốt

  • Luôn nghĩ rằng mình chưa biết hết những câu trả lời, có thể có gì đó còn làm được tốt hơn và luôn luôn học hỏi. Constructively dissatified.
  • Trao đổi tốt (trong team và với những team khác)
  • Thông cảm với thành viên trong team và với người dùng
  • Đa dạng (bao gồm thành viên với nhiều background kĩ năng khác nhau). Việc này sẽ giúp team có nhiều idea, nhiều góc nhìn và giải pháp tổng quát hơn
  • Có sense về business
  • Tự chủ nhưng có trách nhiệm rõ ràng

Đặc điểm của những Product Manager tốt

  • Trao đổi và thích nghi tốt với nhiều loại người khác nhau
  • Luôn tò mò và tìm kiếm thử thách
  • Có thể xông pha vào những công việc thực tế nhất (dirty work)
  • Có selling skills (để giúp team và mọi người hiểu giá trị những sản phẩm team làm ra, đồng thời rất quan trọng khi chốt scope và timeline)
  • Có thể đóng nhiều vai trò khác nhau (wears a lot of hats)
  • Bình tĩnh khi có áp lực cao

Điểm quan trọng nữa là cần có self-aware, tự nhận ra mình thiếu (hoặc chưa mạnh) điểm nào trong những tính cách trên để trau dồi và cải thiện nó. Như vậy từ từ bản thân mình sẽ là 1 Product tốt, sau này mình lead team làm Product cũng có khả năng thành 1 team tốt và quan trọng nhất, là người dùng sẽ được xài 1 phần mềm giải pháp tốt để giải quyết các vấn đề của họ. Đó là việc vui nhất :)

Subscribe to Think.Forget.Do

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe