Prod #0: Nhập môn về Product Development

Bài viết này của mình là từ cuối 2020 ở blog cũ. Mình chia sẻ lại trên Substack để các bạn có thể tìm đọc nếu mới bắt đầu tìm hiểu về lĩnh vực Product Development.

---

Đặc điểm chung giữa những người phát triển sản phẩm là gì ư? Có lẽ là không ai trong số họ từng học ngành nào tên "Product Developement" ở giảng đường đại học. Tất cả mọi người, theo cách hiểu hơi truyền thống, đều đang làm một công việc trái ngành.

Vì không có một chuyên ngành đào tạo chính thức, có nhiều người cho rằng Product Owner / Product Development Executive không có kỹ năng chuyên môn, cũng như khả năng để hiểu sâu một lĩnh vực cụ thể. Quan điểm này thì mình thấy không đúng. Vì thực tế, vai trò "product development" đòi hỏi những kiến thức & kỹ năng đa dạng, cùng khả năng vận dụng chúng phải thật linh hoạt, khéo léo.

Kiến thức & kỹ năng ấy là gì? có thể học được ở đâu? yêu cầu khả năng tự nghiên cứu, tìm hiểu ở mức độ nào? Mình sẽ cố gắng chắt lọc lại trong bài viết này.

------------------

Ngã ba đường "Product"

Hình ảnh trên có lẽ là một trong những minh họa phổ biến nhất mô tả vai trò người làm Product. Đại ý của nó là để hiểu, làm được công việc quản lý & phát triển sản phẩm, bạn cần tìm hiểu cũng như nắm được một loạt kiến thức trong 3 lĩnh vực khác nhau: UX Design, Technology và Business.

Tại sao phải biết kiến thức từ nhiều lĩnh vực như vậy: lý do thực tế nhất bởi bạn sẽ là người làm việc hàng ngày với những chuyên gia trong 3 lĩnh vực trên: UX Designer, Technology Developer và Business Development Manager. Kiến thức là điều cần thiết giúp bạn có khả năng giao tiếp hiệu quả với họ trong công việc hằng ngày, hiểu được suy nghĩ, chia sẻ và các yêu cầu mà từng bên đề xuất trong một dự án chung. Bạn, chứ không phải ai khác, là nhân vật trung tâm trong việc đảm bảo toàn bộ nhóm phát triển sản phẩm với những con người từ các mảng chuyên môn khác nhau có thể giao tiếp rồi làm việc hiệu quả.

Ừ giờ bạn đã hiểu bạn phải học hỏi từ 3 lĩnh vực cơ bản, nhưng bạn có biết chính xác là nên học gì giữa biển trời kiến thức không? Một trong những kĩ năng cơ bản của Product Owner là "ưu tiên" (prioritisation) - bạn cần biết những mảng kiến thức nào nên ưu tiên tìm hiểu, tại sao chúng hữu ích, và ngược lại, những mảng kiến thức bạn không cần thiết quan tâm đến.

Hi vọng đây sẽ là danh mục kiến thức hữu ích cho những bạn đang có mong muốn / kế hoạch bước vào lĩnh vực phát triển sản phẩm (như mình cách đây 1 năm).

------------------

Technology

Công nghệ hẳn là phần nhiều bạn trẻ, trong đó bao gồm mình, e dè nhất khi muốn dấn bước vào lĩnh vực phát triển sản phẩm. Có lẽ bởi trong hình dung của các bạn, PM (product manager) hay PO (product owner) phải là những chuyên gia công nghệ như Mark Zuckerberg, Evan Spiegel, . . . được đào tạo bài bản hoặc có nền tảng chuyên môn sâu về data engineering, coding, system architect gì đó.

Mình đồng ý rằng có kiến thức chuyên môn về công nghệ là điểm cộng lớn cho vị trí Product Owner, tuy nhiên, chuyên môn này chưa bao giờ là điều bắt buộc ở những công ty công nghệ hiện nay, đặc biệt các công ty đã có phân hóa vai trò chuyên môn. Product Owner không cần phải hiểu sâu biết rộng về công nghệ như các Program Developer, Data Scientist hay System Engineer để có thể xây dựng nên một sản phẩm tốt.

Vậy nếu không bắt buộc phải biết tất cả mọi thứ về công nghệ, Product Owner tối thiểu cần nắm được gì?

1. The Stack

Khi các chuyên gia công nghệ trong công ty nói đến thuật ngữ "the stack", họ đang đề cập đến những phần mềm, công nghệ mà công ty sử dụng để phát triển những tính năng thuộc sản phẩm của bạn. Một cách đơn giản, "stack" là thứ làm cho sản phẩm thực sự hoạt động. Từ khi user đăng nhập vào ứng dụng, thực hiện tìm kiếm rồi sử dụng một dịch vụ cụ thể, cho tới khi thanh toán thành công hay hủy bỏ một giao dịch , . . . tất cả đều do "solution stack" đảm nhiệm vai trò chính.

Cách học nhanh nhất - Dành thời gian trao đổi cùng với Technical Engineer là cách khả thi nhất. Lắng nghe họ chia sẻ, ghi chú lại tên của những công nghệ, nền tảng được họ nhắc đến, sau đó tìm kiếm trên Google những tài liệu cơ bản có thể giúp bạn hiểu được khái quát về chúng. Bắt đầu đặt những câu hỏi như tại sao công ty mình sử dụng công nghệ này mà không phải công nghệ nào khác cho tính năng của team, và thực tế chúng được xử lý như nào, rủi ro hay hạn chế có thể sẽ gặp khi nâng cấp tính năng, . . .

Điều này giúp gì cho một Product Owner? - Hiểu được về stack giúp bạn theo dõi được các kĩ sư công nghệ thảo luận ra sao trong mỗi cuộc họp về chuyện "Tính năng này để làm được, cần ứng dụng công nghệ A mà không phải B", "Giải pháp này phù hợp với công nghệ của công ty hơn, mình không nên chọn giải pháp kia", . . . Từ đó bạn sẽ thực tế hơn trong việc lựa chọn giải pháp, ý tưởng phù hợp trong giai đoạn phát triển sản phẩm. Biết được rằng mỗi lựa chọn mình đề xuất có tác động đến bao nhiêu lớp công nghệ, bạn sẽ nhận thức được tính phức tạp, rủi ro và khả thi của chúng.

Câu chuyện của mình - Trong giai đoạn phát triển nhóm tính năng "ads performance tracking & analysis", mình đã phải tìm hiểu thật kĩ đội ngũ phát triển tính năng đang sử ngôn ngữ lập trình nào (Python hay SQL)? thu thập dữ liệu từ cơ sở nào (Firebase hay MongoDB)? stack thuê ngoài hay tự build? giới hạn dữ liệu có thể xử lý và chi phí tương ứng? . . . để cân nhắc lựa chọn những metrics phù hợp với khả năng thu thập (collect), chuyển đổi (transform) hay biểu thị (visualise) data của team. Nếu không nắm rõ những điều trên, mình chắc chắn không thể biết được phải dựa vào đâu để đo lường hiệu quả các campaign ads trên MoMo.

2. System Architeture

Nếu "stack" đại diện cho những công nghệ đang được sử dụng, thì "system architecture" (kiến trúc hệ thống) đại diện cho cấu trúc các loại công nghệ này được tổ chức và hoạt động cùng nhau. Bạn cần phải hiểu về "System architecture" bởi đây cũng là một kiến trúc cơ bản của sản phẩm mà bạn đang phụ trách, dù cho nó tập trung theo hướng nhìn công nghệ nhiều hơn. Những thiết kế sản phẩm khai thác tốt hành vi người dùng không chỉ phản ánh qua bề nổi sản phẩm (product interface) mà còn gán bản chất vào trong hệ thống, kiến trúc công nghệ bên dưới.

Cách học nhanh nhất - Tương tự như trên, hãy hỏi và lắng nghe từ các developer / engineer. Từ product flow ban đầu bạn thiết kế, đội ngũ công nghệ sẽ nghiên cứu sâu và đưa ra cấu trúc hệ thống phù hợp nhất để đáp ứng được cả luồng tính năng của sản phẩm và trải nghiệm người dùng ở front-end.

Điều này giúp gì cho một Product Owner? - Khi đã hiểu được về kiến trúc cơ bản, bạn sẽ bắt đầu tư duy về sản phẩm như một hệ thống, tính liên kết giữa các thành phần bên trong product sẽ chặt chẽ, khoa học và tối ưu hơn. Hơn nữa, nắm rõ từng thành phần liên kết với nhau ra sao, sẽ giúp bạn đưa ra quyết định hiệu quả hơn khi muốn thay đổi, đánh đổi hay bổ sung các thành phần vào hệ thống lớn. Sản phẩm của bạn tiếp tục phát triển mà không sợ bị đứt gãy vì tính phi logic hay thiếu đồng nhất.

Câu chuyện của mình - Mình đang phụ trách một dự án phát triển hệ thống notification mới cho app MoMo. Sau gần 3 tuần nghiên cứu để đề xuất ra luồng tính năng bề mặt, mình gửi lại cho team Data Platform và nhận lại được một cấu trúc hệ thống như này. Nhờ có nó, mình hiểu sâu hơn về chính sản phẩm mình đang làm, và đánh giá lại từng thành phần tính năng vận hành bản chất ra sao, lại còn nhận ra được những tiềm năng có thể khai thác thêm trong tương lai. Quá tuyệt vời!

3. Data model & tracking

Làm việc ở một công ty công nghệ, việc làm quen và sử dụng data hàng ngày là chuyện hiển nhiên với từng nhân viên, đặc biệt là PM / PO. Bắt đầu từ "data model" - bạn cần hiểu rõ cách thức thông tin được ghi nhận, tổ chức và kết nối ra sao trong hệ thống. Tiếp đến, là nắm rõ như lòng bàn tay về phần data thuộc sản phẩm của mình, từng hành động của user, từng thay đổi trong hệ thống cùng người dùng được thu thập ra sao, . . . để từ đó biết xây dựng hệ thống đo lường hợp lý.

Product Owner có cần biết về program language như SQL / Python / . . . hay không? Câu trả lời là có nếu việc sử dụng những ngôn ngữ này giúp bạn tiếp cận data của hệ thống thuận lợi, nhanh chóng hơn. Sẽ thật tốt, nếu bạn có thể tự viết một vài câu querry cơ bản để lấy được data mà bạn đang cần. Còn thông thường, sẽ có Business analyst / Data analyst giúp bạn transform được data thành thông tin có ích. Quan trọng nhất, vẫn là bạn có nắm được logic cần thiết để tìm đúng data bạn cần cho vấn đề / câu hỏi cần trả lời hay không

Cách học nhanh nhất - Tìm hiểu thêm về chủ đề Product Analyst thông qua những blog hữu ích (ví dụ https://segment.com/academy/) hoặc trao đổi trực tiếp với Business Analyst / Data Analyst / Data Platform Manager. Học thêm về SQL có lẽ là gần như bắt buộc nếu bạn muốn thực sự hiểu sâu hơn, khai thác tốt hơn về data, cũng là cách rèn luyện tư duy data nhạy bén hơn.

Điều này giúp gì cho một Product Owner? - Rõ ràng nhất là bạn sẽ đo lường được hiệu quả của giải pháp bạn thiết kế và xây dựng nên, thông qua data collection & analysis. Sâu hơn, hiểu biết về "data model" giúp bạn có khả năng nhận biết được thông tin nào có thể khai thác để khiến sản phẩm tốt hơn, cũng như nhận thức được khả năng khai thác những thông tin này dễ dàng hay khó khăn. Data chính là ngôn ngữ chung nhất cho thế giới sản phẩm công nghệ, đặc biệt khi bạn nắm vai trò trung tâm trong thế giới ấy.

Câu chuyện của mình - Lúc mới bắt đầu mình gặp hạn chế vì không thành thục về SQL , lại không biết rõ về data model cùng các tracking event sẵn có của app. Việc đó gây khó khăn khi mình muốn đề xuất xây dựng tính năng mới mà không biết sử dụng success metrics nào. May rằng mình đã có kinh nghiệm làm Performance Marketing trước đó, việc tìm hiểu về data của công ty không quá nhiều khó khăn. Đến hiện tại, mình vẫn chưa tự viết một câu code SQL nào, nhưng hiểu đủ rõ về data model cùng các tracking event đang được gán trên hệ thống, từ đó viết "data brief" thật chính xác gửi cho Data Analyst. Chỉ mất 3 - 4 ngày, mình đã có dashboard thu thập đầy đủ dữ liệu và phân tích ra những thông tin giá trị về sản phẩm.

4. Điều bạn không nên quá tập trung

Programming. Bạn không cần biết quá nhiều về lập trình, vì bạn không phải lập trình viên.

Trừ khi bạn đang ở một start-up quy mô nhỏ, nếu không, phần lập trình này sẽ thuộc về team Tech. Một chút kiến thức về programming sẽ rất tốt để bạn có thể trao đổi hoặc review một số công việc liên quan đến programmer, nhưng đừng nhúng tay quá sâu. Vì còn nhiều phần việc khác đang chờ bạn giải quyết, đặt niềm tin chuyên môn vào các thành viên khác trong đội nhóm là rất quan trọng.

Cá nhân mình thì không có nền tảng về lập trình, cũng chỉ tự học thêm về SQL và Python đủ để hiểu được những lệnh cơ bản, và rèn luyện tư duy logic thêm nhạy bén. Còn để dành thời gian học Advanced Python / Java Script / C++ / . . . chắc mình xin nhường lại cho các chiến hữu của team :))

------------------

Business

Bạn nào có background học business như mình, hẳn sẽ thấy đây là lợi thế cho các bạn để bắt đầu với lĩnh vực product development. Nhưng cũng có knowledge this, knowledge that, nên việc lựa chọn kiến thức business nào hữu ích cho một Product Owner / Product Manager cũng thực sự cần thiết.

1. Project management

Có thể bạn không biết? Product owner chính xác cũng là project owner. Việc xây dựng tính năng chưa chắc đã cần bạn, nhưng việc quản lý các đầu việc xây dựng tính năng ấy chắc chắn thuộc về bạn. Từ việc chọn ra tính năng nào cần được ưu tiên phát triển, đến việc chia nhỏ công việc, điều phối từng thành viên trong nhóm ra sao cho hợp lý, . . . sẽ đòi hỏi kỹ năng quản lý dự án phi thường từ bạn.

Cách học nhanh nhất - Không có cách nào để học nhanh được kỹ năng này, bạn phải chủ động rèn luyện công việc ấy mỗi ngày. Quản lý dự án đòi hỏi rất nhiều kinh nghiệm, tư duy mạch lạc, sự chủ động và khả năng giao tiếp hiệu quả nơi bạn. Cá tính cũng sẽ là một phần có ảnh hưởng lớn đến khả năng quản lý hoạt động của một Product Owner. Nếu bạn là một người không có tính kiên nhẫn tuyệt đối, sự bình tĩnh và lý trí ở những thời điểm tranh luận gắt gao, bạn không nên và khó lòng trở thành một Product Owner/Manager với kỹ năng quản lý xuất sắc. Sau đây là một số lời khuyên từ cá nhân mình:

- Sử dụng công cụ quản lý dự án như JIRA, Asana, Trello, ProductPlan,. . . hàng ngày. Nhiều bạn prefer dùng Excel để thiết kế & quản lý project timeline, nhưng mình thấy đa phần không thành công, hoặc không duy trì được lâu dài. Mình suggest những công cụ trên sẽ mang tính hiệu quả hơn, và tiết kiệm thời gian hơn.

- Trao đổi thường xuyên với các thành viên để hiểu trước được những hạn chế, khó khăn và rủi ro có thể gặp phải khi họ nhận task từ dự án. Đồng thời, bạn sẽ xây dựng được sự cảm thông để có thể chia sẻ hiệu quả những khó khăn này, giúp team nhanh chóng khắc phục để hoàn thành công việc trước dead-dead-dead line.

- Đảm bảo thông tin được truyền đạt thống nhất và xuyên suốt trong & ngoài team. Hầu hết những chậm trễ hay biến xấu xảy ra khi có một ai đó trong team hiểu sai yêu cầu của dự án, đặc biệt là yêu cầu chi tiết trong Product development document hay Task delivered card. Dù là văn nói hay văn viết, bạn cũng phải giao tiếp thật chính xác, rõ ràng và đầy đủ.

Câu chuyện của mình - Mình có quá nhiều bài học về quản lý dự án trong 1 năm qua =)) Có những thời điểm, phải take care đến 4 dự án (tương đương 4 nhóm tính năng), "trade-off" và "prioritise" là 2 công việc giải quyết mỗi ngày. Và trước mỗi lần ra quyết định, mình lại nhớ đến một câu hỏi quan trọng: "How much does it worth?" (Quyết định này đáng giá từng nào?). Đôi khi mình quyết định sai, phải vài tuần sau kết quả trả lại mới giúp bản thân nhận ra điều đó. Đau đầu lắm chúng bạn à! Được cái mừng là dạo gần đây tính tổ chức công việc đã ok hơn.

2. Modelling impact

Hiểu được data model quan trọng 1, thì hiểu về business model quan trọng 2, đặc biệt là những ảnh hưởng của business model đến product của bạn. Thường những quyết định được đưa ra không theo công thức hay tiêu chuẩn nào hiếm khi mang lại kết quả tích cực. Việc xây dựng được một hệ thống chỉ số và công thức tốt, dựa trên các nguyên tắc của business, sẽ giúp bạn đưa ra quyết định hiệu quả hơn khi có những tranh luận trong team về việc tính năng nên phát triển tiếp theo, vấn đề nào nên được khắc phục ngay lập tức.

Cách học nhanh nhất - Ngồi xuống cùng Business side, ví dụ team Business Development, Growth hay Marketing để thảo luận về một mô hình bao gồm những chỉ số phù hợp giúp bạn đánh giá, phần loại được tính hiệu quả của các quyết định / lựa chọn.

Điều này giúp gì cho một Product Owner? - Phân tích dựa theo model là một cách thuyết phục giúp bạn kiểm tra được những giả thuyết, nhằm chắc chắn rằng tính năng bạn đề xuất có tiềm năng tốt, có thể giải quyết vấn đề của business và mang lại các chỉ số thành công có thể đo lường. Đồng thời, bạn dễ dàng so sánh được chi phí cơ hội giữa những dự án, tính năng khác nhau mà bạn có thể làm.

Câu chuyện của mình - Trong mảng marketing platform, có lần mình phải ngồi thảo luận cùng Growth về câu hỏi "Trong 10 format ads khác nhau có thể xây dựng trên hệ thống, nên ưu tiên những format ads nào ở quý tiếp theo?" Bọn mình đã lập ra một bảng spreadsheet đánh giá, với một số câu hỏi cụ thể như:

(1) Thời gian để thiết kế và xây dựng mỗi format ads? Nếu đưa vào sử dụng sớm hơn mỗi tuần thì có thể mang thêm về bao nhiêu lợi nhuận?

(2) Mức độ, tần suất sử dụng của mỗi format ads dựa theo nhu cầu của business: bao nhiêu lần sử dụng một ngày? bao nhiêu người sử dụng một tuần? có thể sử dụng bền vững trong 1,2 năm tiếp theo?. . .

(3) Chi phí vận hành tối thiểu cho mỗi format ads? Mối tương quan giữa chi phí và doanh thu dự kiến? Tỷ lệ chuyển đổi trung bình của mỗi format?. . .

Với cách phân tích dựa theo model tính toán chi tiết bằng điểm (ranking), rất nhanh đã có thể quyết định sẽ ưu tiên tính năng nào cần xây dựng, thay vì cách lựa chọn cảm tính như trước đây.

3. Product operation management

Quản lý product & business operation là cách bạn thiết kế quy trình có tính hệ thống giữa việc sản phẩm sau khi launch sẽ được vận hành ra sao, xử lý như nào về phía business khi có lỗi tính năng, đo lường hiệu quả bằng product metrics gì khi thử nghiệm tính năng mới, tương tác & liên kết ra sao với những tính năng của các product team khác, . . .

Một số product owner xem nhẹ vai trò của việc design một operation flow giữa Product & Business, tuy nhiên, có nhiều dự án mình chứng kiến cho thấy, một sản phẩm với tính năng được thiết kế tuyệt vời nếu không được quản lý vận hành sâu sát và chi tiết, sẽ vẫn thất bại như thường.

Cách học nhanh nhất - Nếu trong product team có Product Operation / Product Risk team, hãy dành thời gian trao đổi với họ về luồng sản phẩm của bạn. Họ sẽ giúp bạn hiểu những vấn đề và rủi ro tiềm tàng khi sản phẩm vận hành chính thức, đồng thời cho bạn giải pháp để tiếp tục hoàn thiện, hoặc ngay lập tức xử lý vấn đề khi lỗi xảy ra.

Điều này giúp gì cho một Product Owner? - Sản phẩm được đưa vào hoạt động mới là khởi đầu của hành trình, những kiến thức về product operation management sẽ giúp bạn quản lý tốt quy trình hoạt động, tìm ra những vấn đề và xử lý tức thì, phân tích hiệu quả hoạt động (product analysis) và định hướng được những ưu tiên cần phải cải thiện, phát triển trong các tuần tiếp theo.

Câu chuyện của mình - May mắn là mình từng thuộc team Product Operation, nên aware được kha khá vấn đề trước khi trở thành Product Owner. Điều này giúp mình có cái nhìn khái quát và hệ thống hơn về vị trí của sản phẩm trong toàn bộ hệ sinh thái ứng dụng ở MoMo. Hiểu rõ quy trình product operation, mình giảm thiểu được những rủi ro không đáng có trước khi mỗi format ads được launch trên app. Ngoài ra, khi có bug báo về, mình có phương án xử lý nhanh hơn thông qua sự hỗ trợ của các bạn trong team Product Ops.

4. Điều bạn không nên tập trung

Đừng lãng phí thời gian vào những suy nghĩ / kiến thức xa vời liên quan đến chiến lược kinh doanh, kế hoạch tăng trưởng 3 - 5 năm hay một loạt vấn đề khác thuộc chuyên môn của người vận hành hoạt động business. Việc của bạn là tập trung vào giải pháp liên quan trực tiếp đến trải nghiệm của người dùng, và đảm bảo sản phẩm sẽ được nhóm khách hàng mục tiêu của công ty yêu thích, thử nghiệm, sử dụng lâu dài.

Cũng có một số sản phẩm mang tính đặc thù hơn, khiến bạn phải quan tâm nhiều đến vấn đề về business hơn. Ví dụ khi bạn xây dựng một internal product - marketing platform cho công ty như mình. Bạn sẽ cần tìm hiểu nhiều hơn về các chỉ số marketing performance của công ty, các hoạt động marketing đang diễn và vấn đề nằm sâu bên trong khiến kết quả chưa thể cải thiện. Tuy nhiên, vẫn có ranh giới giữa việc phát triển sản phẩm, xây dựng giải pháp và việc sử dụng / vận hành sản phẩm đó để tạo ra kết quả kinh doanh. Và mình luôn nhắc nhở bản thân đang đứng ở bên nào của ranh giới, không nên dẫm vào chuyên môn của người khác (dù có lúc mình cũng có những ý tưởng riêng, quan điểm riêng cho vấn đề business).

------------------

UX Design

UX design là một phần khá hấp dẫn cho người mới, vì tính trực quan, minh họa sinh động và giàu yếu tố cảm xúc bên trong. Tuy nhiên, cần ý thức rằng, UX design không phải là art, mà là science. Bạn cần thực sự nghiêm túc xác định những kiến thức liên quan đến design mà một Product Owner cần có trong công việc.

1. Design material

Khi thiết kế sản phẩm, dù là sản phẩm công nghệ hay lĩnh vực khác, bạn sẽ phải tận dụng những thành phần mẫu sẵn có, gọi là "design material" (hoặc design patterns). Đó là các thành phần cơ bản đã được thiết kế sẵn, quy chuẩn thành hệ thống (Style guide). Mỗi một chiếc icon, button, font chữ, màu sắc, . . . đều được team Design Architecture đưa vào guideline, trở thành các material cơ bản cho Product & Front-end Engineering tận dụng. Điều này giúp mỗi bạn product vừa tiết kiệm thời gian trong việc tận dụng những yếu tố sẵn có, vừa đảm bảo tính thống nhất giữa các tính năng, dịch vụ khác nhau trong một sản phẩm tổng thế.

Ở những công ty đang mở rộng nhiều nhóm sản phẩm, tính năng, "design material" có vai trò rất quan trọng nhằm giữ được "consistent design" hay "consitent user experience".

Cách học nhanh nhất - Hãy hỏi trực tiếp team Design, xin họ chia sẻ hệ thống "design material" / "style guide" của riêng công ty. Hoặc cũng có thể trao đổi thường xuyên với team App, team Front-end Engineer bạn sẽ biết được những UX / UI kit đang được áp dụng. Ngoài ra, material.io là nguồn tham khảo hữu ích cho bạn.

Điều này giúp gì cho một Product Owner? - Trước hết là giúp bạn dễ dàng và nhanh hơn trong quy trình thiết kế sản phẩm. Từ một bản low-fidelity prototype, bạn có thể gần như ngay lập tức lựa chọn element phù hợp từ material library để áp dụng. Đôi khi, việc nghiên cứu những design material có sẵn cũng giúp bạn có thêm nhiều lựa chọn UX/UI tốt hơn cho sản phẩm của mình, mà lại đảm bảo nhất quán với toàn bộ ứng dụng.

Câu chuyện của mình - Nhiều product owner, trong đó có mình, thường có nhu cầu sử dụng một format communication như "X-banner" để cập nhật, nhắc nhở hay thông báo nội dung quan trọng đến user. Trước đây thì mỗi PO sẽ có một UX/UI design khác nhau trong đầu. Còn bây giờ, khi team Design đã tổng hợp và chuẩn hóa lại bộ X-banner (như dưới đây), công việc của các PO trở nên thật dễ dàng: chọn lựa mẫu phù hợp với sản phẩm của mình nhất, và đặt vào trong product proto-type. Đến khi develop, công việc của Front-end Engineer cũng dễ dàng hơn vì material này đã có sẵn code đính kèm.

2. User experience research

Vượt trên vai trò phát triển sản phẩm, PO có vai trò còn là tiếng nói đại diện của người dùng trước công ty. Nếu bạn không thực sự hiểu người dùng muốn gì, sẽ chẳng bao giờ xây dựng được một sản phẩm tốt (chưa nói đến tuyệt vời). Từ việc phỏng vấn từng người dùng cá nhân, đến survey khảo sát hàng chục ngàn khách hàng thực tế, cho tới AB test ngay trên app với một nhóm user nhất định, bạn có nhiều cách khác nhau để tiến thêm một bước trong việc thấu hiểu người dùng.

Thiết kế sản phẩm, suy cho cùng, là thiết kế giải pháp cho vấn đề của người dùng. Và bởi vậy, bạn trước hết phải hiểu cho đúng vấn đề của họ là gì.

Cách học nhanh nhất - Bắt đầu từ những khảo sát cá nhân với bạn bè của mình, sau đó bắt đầu làm quen với những cách thức khảo sát định lượng trên quy mô lớn hơn. Bạn sẽ cần tính toán một vài vấn đề khi thực hiện:

- Tập mẫu (sample size) cần tối thiểu là bao nhiêu để đảm bảo kết quả đo là "significant"

- Thiết kế câu hỏi và các lựa chọn trả lời như nào để đảm bảo "unbiased", "non-leading", . . .

- Thu thập & phân tích kết quả trả lời bằng kỹ năng nào thì phù hợp

. . .

Ngoài ra, mình khuyến khích các bạn tìm hiểu thêm về AB test in app (ví dụ qua Firebase), nếu công ty bạn đang sử dụng những công nghệ cho phép thực hiện AB test.

Điều này giúp gì cho một Product Owner? - User experience research giúp bạn khẳng định được những giả thuyết nào là đúng (hoặc sai) trong quá trình thiết kế sản phẩm. Trước khi chốt được phương án cuối cùng launch cho toàn bộ người dùng, người làm product nên thực hiện testing để biết được lựa chọn nào tối ưu hơn cả. Việc này có thể ảnh hưởng đáng kể đến kết quả sau cùng của dự án, giúp bạn không phải đánh đổi thời gian để đi sửa chữa những sai lầm mà vốn dĩ có thể ngăn được nếu bạn hiểu rõ hơn về hành vi người dùng.

Câu chuyện của mình - Trong một dự án phát triển màn hình Home mới, có một insight được đưa ra là "nếu ứng dụng cho phép người dùng được tùy chỉnh dịch vụ mà họ muốn nhìn thấy và sử dụng, tỉ lệ tương tác và chuyển đổi sẽ tốt hơn". Để khẳng định được insight này, mình không thể chỉ hỏi một vài người rồi tự quyết định, mà phải thiết kế một số phương án khác nhau: trong đó có phương án cho phép user tùy chỉnh dịch vụ mà họ yêu thích. Sau khoảng 4 - 6 tuần release cho một nhóm user trên app, tỉ lệ chuyển đổi đã tăng hơn 10% - một con số quá bất ngờ! Và nhờ vậy, mình đã đủ tự tin để tiếp tục phát triển design mới theo hướng "self-personalisation" (trao quyền tùy chỉnh cho user). Chi tiết của câu chuyện này, xin phép chia sẻ trong một bài viết khác.

3. Idea prototype

"Prototype idea" - chắc chắn là một kỹ năng quan trọng để bạn giao tiếp được với team Design & Front-end Engineer. Hiểu đơn giản là khả năng bạn biểu đạt ý tưởng dưới dạng visual mockup từ giai đoạn sớm để có thể trao đổi và lấy thêm ý kiến từ các designer hoặc app developer. Khi bạn prototype, bạn cho thấy rõ hơn về việc người dùng tương tác, trải nghiệm ra sao với sản phẩm. Và bởi con người thường suy nghĩ mọi thứ bằng hình ảnh tốt hơn, nên prototype là cách giao tiếp hiệu quả khi mọi thứ đang dừng ở mức ý tưởng, giúp mọi thành viên trong team có cái nhìn chung về giải pháp mà bạn đang đề xuất.

Cách học nhanh nhất - Đầu tiên là dùng giẩy & bút để phác họa những ý tưởng nguyên bản nhất của bạn về product solution. Tiếp đến, học cách sử dụng một trong những công cụ prototyping như Figma, Sketch, InVision, . . . để mô tả chính xác & sinh động hơn UX design của mỗi solution option. Bạn cũng dễ dàng cập nhật online khi có nhu cầu điều chỉnh thiết kế.

Điều này giúp gì cho một Product Owner? - Trong hầu hết dự án, product design phải đi trước product development ít nhất 1 - 2 tuần, bởi chi phí để thay đổi design thấp hơn rất nhiều so với chi phí thay đổi một đoạn code sản phẩm. Và sẽ ít có chuyện designer ngồi trao đổi chi tiết cùng developer về một dự án cụ thể như của bạn, họ có những chuyên môn khác nhau và cùng không hiểu hết được về tính năng bạn muốn xây dựng. Việc sử dụng prototype chính là cách gần nhất giúp bạn giao tiếp với cả 2 phía ngay từ ban đầu về ý tưởng thiết kế + phát triển sản phẩm.

Câu chuyện của mình - Mình vẫn thường sử dụng Figma để vẽ prototype cho các tính năng, sản phẩm mới. Từ prototype đến final design luôn có một khoảng cách khác biệt lớn, tuy nhiên nhờ có prototype là định hướng ban đầu, team Design & App Development sẽ thảo luận thêm với mình rồi tạo ra thiết kế tuyệt vời cuối cùng: vừa đạt được product requirement từ PO, vừa đảm bảo tính xuyên suốt cho trải nghiệm của user trên ứng dụng tổng thể.

4. Điều bạn không nên tập trung

Đừng cố gắng trở thành một visual designer chuyên nghiệp, cũng đừng cố gắng vẽ ra những bản prototype hoàn hảo. Điều này vừa khiến bạn mất thời gian khi dẫm lên chuyên môn của người khác, vừa không có gì đảm bảo thiết kế của bạn đáp ứng mọi tiêu chí cơ bản của team Design. Trừ khi bạn có xuất phát điểm là một designer, nếu không, hãy tin tưởng phần visual/ UI cho người có chuyên môn, còn bạn phải thật sự để tâm đến product flow / UX flow cơ bản có được đảm bảo trong final design hay không.

------------------

Conclusion

Trên đây mình đã mô tả nghe có vẻ chi tiết, nhưng thực ra còn khá nông về những chủ đề mà một bạn mới bước vào lĩnh vực Product development cần tìm hiểu. Bản thân mình cũng vẫn đang tiếp tục trau dồi những topic này mỗi ngày, qua sách báo, podcast, qua công việc thực tế và trao đổi thường ngày với những người có chuyên môn. May mắn của mình là được làm việc trong môi trường cởi mở, rất nhiều anh chị, bạn bè sẵn sàng giúp đỡ, hướng dẫn và thẳng thắn feedback cho công việc của mình.

Hi vọng bạn sẽ tìm được môi trường phù hợp để phát triển, và hi vọng bài viết này đã giúp bạn có thêm một chút thông tin hữu ích, để hoàn thiện bản thân trong lĩnh vực Product Developement.

Note: Bài viết trên có cấu trúc dựa trên bài viết gốc MVPM: Minimum Viable Product Manager của tác giả Brandon Chu. Mình đã viết lại theo cách hiểu cá nhân, đồng thời thêm vào câu chuyện thực tế từ bản thân để bạn đọc dễ hiểu hơn. Các bạn nhớ tìm đọc thêm bản gốc nhé!

Comment thêm bất cứ câu hỏi hay chủ đề nào về Product mà bạn muốn biết, mình sẽ dành thời gian giải đáp :")