Bài viết gốc: https://simpleproductmind.com/product-management-co-ban-2-product-team/
Đã bao giờ bạn thắc mắc về việc các sản phẩm công nghệ cao như Zalo, Snapchat, Grab được xây dựng như thế nào chưa? Ví dụ như làm sao để ông Grab quyết định sẽ thêm tính năng XYZ vào ứng dụng, làm sao để ông Tiktok tạo ra được một cái Feeds gây nghiện cho toàn thế giới như thế?
Ngày trước khi còn đi code, mình thường nghĩ tới một ông Founder ngồi trong 1 căn phòng bề bộn, viết ra chương trình thay đổi thế giới. Hoá ra không phải, thế giới không vận hành như thế. Để tạo ra một ứng dụng, một sản phẩm được hàng triệu người dùng yêu thích, thông thường chúng ta sẽ cần đến một đội ngũ, một team với các kỹ năng đa dạng bổ trợ cho nhau – gọi là Product Team.
Một sản phẩm tuyệt vời
Ok, trước khi nói về team làm ra một sản phẩm tuyệt vời thì chúng ta cần phải xem xét như thế nào là một sản phẩm tuyệt vời trước.
Mình định nghĩa đơn giản thế này, một sản phẩm tuyệt vời làm một sản phẩm giúp user của nó giải quyết được vấn đề của họ theo một cách hết sức tuyệt vời.
Ví dụ, con Laptop 3 triệu của mình không phải là một sản phẩm tuyệt vời vì mặc dù nó giải quyết được vấn đề lướt web của mình, nhưng theo một cách rất tệ bởi vì nó rất lag, hiển thị rất xấu.
Taxi truyền thống không phải một sản phẩm tuyệt vời bởi vì mặc dù nó giải quyết được vấn đề đi lại của mình nhưng mỗi lần mình gọi xe rất lâu, lên xe thì có mùi hôi rất khó chịu.
Tinder là một sản phẩm tuyệt vời vì nó giúp mình kết nối với các em bé xung quanh, trải nghiệm mượt mà gây nghiện, mình có thể lướt Tinder 3 tiếng liền ( ví dụ thôi ).
Macbook là một sản phẩm tuyệt vời vì nó giải quyết được nhu cầu lướt web của mình rất mượt mà, màn hình rất đẹp, quả táo rất sang trọng để mình đem ra The Coffee House khoe.
Lấy ví dụ Tinder, để tạo ra 1 sản phẩm tuyệt vời cho mình, Tinder có một số yếu tố sau:
Thứ nhất, Tinder giải quyết được một vấn đề cốt lõi cho user của nó là mình, đó là nhu cầu kết nối với các bé ở xung quanh. Đây là yếu tố cốt lõi, không có nó thì mọi thứ đều là bỏ đi. Mình nhấn mạnh, một sản phẩm tuyệt vời cần giải quyết được nhu cầu, vấn đề cốt lõi cho user của nó. Thứ 2 là UI/UX ( User Interface/User Experience ): đội ngũ Tinder ứng dụng nhiều trick tâm lý gây nghiện, khá tương đồng với việc lướt Feed Tiktok, Facebook Thứ 3, thương hiệu và thông điệp của Tinder giúp mình có thể lướt Tinder ngay tại nơi công cộng mà không có cảm giác lén lút như các trang Online Dating khác
Product Team
Tưởng tượng bạn và mình mới join team Tinder ngày đầu tiên với vị trí Product Executive, thử làm quen với đồng đội mới nhé.
Designer
Người đầu tiên bạn cần làm quen sau sếp của bạn chính là Designer, anh chị em designer chính là những người kề vai sát cánh với bạn trong việc tạo ra UI/UX tuyệt vời. Tất cả những thứ bạn thấy trong ứng dụng Tinder đều được vẽ ra bởi các designer, từ layout của một màn hình cho đến màu sắc của các nút, cỡ chữ… Nhưng sâu xa hơn, Designer còn tham gia vào việc thiết kế toàn bộ trải nghiệm của user trong ứng dụng. UI là thứ bạn thấy, UX là thứ bạn trải nghiệm. UI hoàn toàn là công việc của Designer, còn UX sẽ là công việc của bạn, kết hợp với Designer.
Developer/Tester
Ideas hay ho hay UI tuyệt đẹp đều là vô nghĩa cho đến khi nó thật sự đến tay người dùng – dưới dạng một sản phẩm thật sự. Người làm ra một sản phẩm thật sự để user sử dụng chính là các Developer. Trong ví dụ Tinder ở trên, người thiết kế ra UI/UX là Product & Designer, nhưng người thật sự đem trải nghiệm đó tới user là Developer, chính các dòng code của họ là thứ giúp mình kết nối với em bé cạnh nhà. UI/UX tuyệt vời đến đâu mà lên điện thoại người dùng không chạy được thì cũng bỏ.
Với một sản phẩm phần mềm/Internet như Tinder, Zalo… thì team Developer thông thường sẽ chia thành những team nhỏ hơn ứng với phần việc mà họ đảm nhiệm. Ví dụ sẽ có team Android Developer chuyên làm ứng dụng Tinder Android, team IOS Developer chuyên làm ứng dụng Tinder IOS, team Web Developer chuyên làm ứng dụng Tinder Web, và team Back-End chuyên xử lý logic phía dưới của Tinder, ví dụ như việc làm sao để xác định 2 người Match với nhau chẳng hạn.
Ứng với từng loại sản phẩm, team Developer sẽ được chia thành những team cụ thể khác nhau, nhưng chung quy lại thì họ là người thật sự viết ra các sản phẩm có thể hoạt động được.
Nếu Developer là người viết ra các sản phẩm thì Tester/QC là người đảm bảo sản phẩm hoạt động đúng như những gì đã được định sẵn. Họ là những người quyết định chất lượng của sản phẩm.
Công việc của bạn – một Product sẽ tương tác với anh em Developer/Tester rất nhiều. Bởi đơn giản, họ là người biến idea, các dòng yêu cầu của bạn thành hiện thực.
Data Scientist
Khi bạn bước chân vào thế giới Product, trở thành Product Execute/Product Specialist…, bạn trở thành người ra quyết định. Tất cả đều là các quyết định, tốt hay tệ, bạn phải chịu trách nhiệm với điều đó. Designer sẽ cần bạn quyết định flow sử dụng của user sẽ như thế nào, Developer cần bạn quyết định function hoạt động như thế nào, và quan trọng hơn cả là bạn cần quyết định “Làm sao để cải thiện sản phẩm? Làm tính năng gì tiếp theo? Nghe theo lời khuyên của ai, của user hay của sếp bạn?”…
Data sẽ giúp cuộc sống trở nên dễ dàng hơn. Một ông nào đó nói rằng “Without data, you are just another person with an opinion”. Đúng là như vậy. Thuật ngữ gọi là “Data Driven” hoặc là “Data based desision making”, đại ý là bạn cần dựa vào dữ liệu và sự hiểu biết để ra quyết định, thay vì tự nghĩ ra một cái idea trên trời nào đó.
Các ứng dụng đều thu thập data sử dụng từ người dùng, data sẽ giúp người làm Product hiểu được user đang sử dụng sản phẩm như thế nào, có đúng với mục đích ban đầu chúng ta đưa ra hay không? Giả sử với ứng dụng Tinder, Tinder có một tính năng cho phép bạn có thể thêm một bài hát yêu thích vào profile, như vậy làm sao để ông Product làm ra cái tính năng đó biết được tính năng có hiệu quả hay không?
Để biết một tính năng có hiệu quả hay không, ta phải quay lại với câu hỏi “Mục đích của tính năng là gì?” – giả sử với tính năng mình kể trên của Tinder thì mục đích chính là giúp user tạo thêm cá tính cho profile, từ đó thu hút mọi người hơn, được Match nhiều hơn. Như vậy đích đến cuối cùng sẽ là các user có thêm nhạc vào profile thì sẽ có tỉ lệ Match cao hơn. Ông Product sẽ phải thu thập, ghi nhận tất cả các dữ liệu để chứng minh điều đó. Anh em Data Scientist sẽ là những người hỗ trợ bạn – một Product trong việc phân tích data, visualize data, export data… nhưng cuối cùng chính bạn sẽ là người cần hiểu được data nói gì.
Marketing
Tuỳ vào loại sản phẩm, giai đoạn của sản phẩm mà bạn sẽ tương tác ít, nhiều với team Marketing. Giả sử bạn làm cho một sản phẩm mới chỉ ra thị trường được 6 tháng thì Marketing sẽ tham gia cực kỳ sâu vào team Product, bởi vì họ chính là nguồn sống của sản phẩm, họ là người đem users tới sử dụng sản phẩm.
Product
Ok, bây giờ tới chúng ta. Khi mình nói một người làm Product thì mình đang chỉ các thể loại Product Executive/Product Specialist/Product Owner/Product Manager…, mỗi công ty gọi một kiểu, không biết đường nào mà lần. Nhưng chung quy lại, Product là mảnh ghép cuối cùng, kết nối các team ở trên lại để tạo ra một sản phẩm tuyệt vời.
Đại khái quy trình sẽ như thế này. Bạn, từ dữ liệu lấy từ anh em Data Scientist, từ feedback của user, từ yêu cầu của sếp… có một ý tưởng cơ bản là sẽ làm một tính năng nào đó cho sản phẩm. Thì nhiệm vụ của người làm Product sẽ như thế nào? Làm sao để ý tưởng này ra được thực tế?
Việc đầu tiên, bạn cần xác nhận xem yều cầu, ý tưởng đó có thoả đáng hay không? Đó có thật sự là điều users muốn hay không? Bạn làm điều đó bằng nhiều kỹ thuật, công cụ khác nhau mà chúng ta sẽ thảo luận ở các bài chi tiết hơn, ở mức hiện tại, ta chỉ hiểu chung đây là giai đoạn “Problem Space” – tức là giai đoạn bạn xác nhận, tìm ra vấn đề thật sự cần giải quyết từ ý tưởng cơ bản ban đầu ở trên.
Sau khi đã tìm ra, xác nhận được vấn đề thật sự cần giải quyết cho sản phẩm từ “Problem Space”, ta qua một giai đoạn mới gọi “Solution Space”, như cái tên, giai đoạn này bạn sẽ thiết kế giải pháp cho vấn đề mới tìm đươc. Bạn cũng làm điều đó với nhiều kỹ thuật, công cụ khác nhau, nhưng cơ bản là bạn sẽ làm việc với Designer để thiết kế UX, làm việc với Developer để làm rõ các giới hạn về kỹ thuật, về tính khả thi của giải pháp, làm việc với sếp để có được sự đồng thuận, làm việc với users ( nếu có thể ) để nhờ họ feedback solution mới được thiết kế. Sau khi xong tất cả các bước trên, bạn sẽ có được đống chữ và hình, gọi là “Product Specification” – đây sẽ là tài liệu đưa qua cho đội Developer thực thi.
Xong, xong phần sáng tạo và idea. Bây giờ ta đến phần tay chân nhất – Project Management.
Nhiều người lầm tưởng làm Product thì chỉ cần idea bay bổng, Steve Job’s Vision… Không phải đâu, sau khi đã có spec cho Developer thì ta sẽ bước vào giai đoạn thực thi, thường sẽ chia thành các “Sprint”. Sprint là một idea từ Agile Methodology, đại ý là trong vòng 1 sprint kéo dài khoảng 2-4 tuần, Product Team sẽ release một số tính năng, cải thiện nhất định tới users. Như vậy trong vòng 1 sprint này, bạn phải làm sao để Developer/QC hoàn tất feature đã định trong Product Specification. Thế nên học Project Management đi nhé, tất cả là về Timing, Negociation, Communication…
Nhờ đấng phù hộ, feature của bạn được release đúng thời gian đã định. Bây giờ thế nào? Bạn cần monitor, theo dõi số liệu, theo dõi phản ứng của users, theo dõi phản ứng của các sếp ở trên… chung quy lại là bạn cần theo dõi để xác nhận là feature được đón nhận, được sử dụng đúng như chúng ta đã dự tính ban đầu, nếu không, bạn sẽ cần cải thiện nó.
Kết
Tuỳ vào loại sản phẩm mà Product team sẽ gồm nhiều bộ phận riêng lẻ khác nhau, các team mình kể ở trên chỉ là một phần của bức tranh toàn cục. Họ sẽ là những người bạn tương tác, làm việc chung hàng ngày khi bạn bước chân vào làm Product. Hy vọng bài viết giúp bạn hiểu rõ hơn về công việc làm sản phẩm. Take care!