Product Delivery 101

Cùng khám phá xem Delivery khác gì Discovery

Mar 21, 2024

Hế lôôôô mọi người, mình Ngọc Mai đây. Đầu tiên, mình và team cảm ơn mọi người rất rất nhiều vì đã dành nhiều quan tâm cũng như tương tác tới bài viết Product Discovery 101. Ngoài ra team mình còn các bài viết khác về phân tích Product Management (dùng cho Physical, Service hay Digital Product đều được) mọi người có thể xem tại đây:

Đặt câu hỏi hoặc thắc mắc tại đây:

Cộng Đồng JTBD

Mọi người hãy đặt nhu cầu viết bài trong hội nhóm bọn sẽ dựa vào đó viết bài cho mọi người.😀

Qua lại bài viết thôi nào:

Khi bước chân vào ngành quản lý sản phẩm mình may mắn được đào tạo và làm việc trong những đội sản phẩm cross-functional và chịu trách nhiệm cho cả hai quá trình Discovery và Delivery, đây cũng là hai hoạt động chính của đội sản phẩm mà mình tham gia và hai hoạt động này được lặp đi lặp lại liên tục - continuosly. Sau này, khi có dịp kết nối với các anh/chị/bạn ở các công ty khác nhau và được nghe chia sẻ nhiều “phiên bản" của đội sản phẩm như “feature team", “discovery team", “delivery team”, mình bị bối rối không biết các đội này sẽ hoạt động như thế nào khi cả hai quá trình (Khám phá - Discovery và Cung cấp - Delivery) đều diễn ra liên tục và hỗ trợ lẫn nhau. Discovery giúp cho việc Delivery những sản phẩm phục vụ người dùng tốt hơn và mang lại giá trị cho tổ chức, Delivery giúp các đội ngũ có các bài học thực tế cho quá trình Discovery để ngày càng tạo ra các giải pháp tối ưu hơn.

Như mình đã đề cập ở bài viết trước “Nhiệm vụ của Product Manager là tạo ra giá trị.”

Mà muốn làm được điều này đội product cần tham gia vào cả hai quá trình Discovery và Delivery, Discovery để tìm ra sản phẩm đúng để xây và Delivery để xây dựng, triển khai một sản phẩm có chất lượng. Ở bài viết này mình sẽ cùng mọi người nói về: các phương pháp phổ biến khi làm Delivery, việc cân bằng giữa Discovery và Delivery, cần làm gì để quá trình Delivery thành công.

3 phương pháp phổ biến trong Product Delivery

1. Phương pháp Waterfall

Ở đây chắc mọi người đã nghe nhiều đến mô hình Waterfall (hoặc Top-down) còn được gọi là mô hình tuần tự, tuyến tính đây là một trong những mô hình phát triển phần mềm lâu đời nhất và truyền thống nhất. Sở dĩ gọi đây được gọi là Waterfall bởi vì các bước trong mô hình này sẽ diễn ra một cách tuần tự, bước A hoàn thành sẽ tới bước B và tiếp tụ

Phù hợp với:

Các sản phẩm hoặc dự án yêu cầu sự chính xác cao, ít thay đổi và có sự kiểm soát chặt chẽ, các bước cần được phê duyệt trước khi tiến hành. Ví dụ: các sản phẩm về chính phủ, y tế, ngân hàng.
Các sản phẩm hoặc dự án đã được lên kế hoạch chi tiết, chặt chẽ, tài liệu đầy đủ và scope rõ ràng (nguồn lực, yêu cầu - cả về functional lẫn non-functional, timeline).

Không phù hợp với:

Waterfall không phù hợp cho việc kiểm thử hiệu suất sản phẩm hoặc hành vi người dùng hoặc các thử nghiệm lặp đi lặp lại đòi hỏi tính linh hoạt cao.
Share

2. Phương pháp Lean

Phương pháp Lean được lấy cảm hứng từ các nguyên tắc sản xuất tinh gọn (Lean Manufacturing) của tập đoàn Toyota, phương pháp này tập trung vào tối ưu hóa thời gian phát triển, nguồn lực và chỉ cung cấp những gì người dùng thực sự cần. Kết quả đầu ra của phương pháp Lean là một Minimum Viable Product - MVP (sản phẩm khả dụng tối thiểu). Đây là phiên bản đơn giản nhất của sản phẩm có thể đưa ra thị trường để thu thập phản hồi từ người dùng từ đây đội sản phẩm có thể lặp lại quy trình, cải thiện sản phẩm và tung ra các phiên bản tiếp theo đáp ứng tốt hơn nhu cầu người dùng.

Phù hợp với:

Các sản phẩm cần cập nhật liên tục từ việc thăm dò và lấy phản hồi từ khách hàng.
Phương pháp Lean giúp các nhóm sản phẩm hiểu sản phẩm của họ đáp ứng được thị trường như thế nào và ưu tiên xây dựng các tính năng quan trọng - Product Market Fit.
Đồng thời, phương pháp này còn phù hợp với các đội sản phẩm muốn tiết kiệm chi phí và nguồn lực.

Không phù hợp với:

Phương pháp này sẽ không hiệu quả với các tổ chức có cấu trúc cứng nhắc, yêu cầu tài liệu chi tiết và từng bước trong quá trình phát triển sản phẩm cần được phê duyệt liên tục.
Các sản phẩm hoặc dự án có mục tiêu, ngân sách, và thời gian cố định không thể thay đổi.

3. Phương pháp Agile

Phương pháp Agile (Agile product delivery) là một phương pháp luận nhấn mạnh vào tính linh hoạt, cộng tác và cải tiến liên tục. Nó liên quan đến việc chia nhỏ quá trình phát triển sản phẩm thành các chu kỳ lặp lại ngắn, được gọi là sprint (vòng lặp ngắn hạn). Mỗi sprint tập trung vào việc cung cấp một bộ tính năng hoặc chức năng cụ thể, tiếp thu phản hồi từ khách hàng và các bên liên quan được sử dụng để cải thiện cho sprint tiếp theo.

Phù hợp với:

Các sản phẩm cần cập nhật liên tục từ việc thăm dò và lấy phản hồi từ khách hàng.
Đồng thời, phương pháp này còn phù hợp với các đội sản phẩm muốn release các version nhỏ, thu thập phản hồi từ khách hàng, tăng giá trị sản phẩm và sửa lỗi nhanh chóng

Không phù hợp với:

Agile sẽ ít phù hợp với các sản phẩm fixed cứng về requirements, thời gian và chi phí.

Nhóm mình sẽ có các bài viết chi tiết về các phương pháp này, mọi người yên tâm nhé 😊.

Cân bằng giữa Discovery và Delivery

“Các bạn giải quyết vấn đề của người dùng như thế nào?” mình trong thời điểm đầu khi làm quản lý sản phẩm mình dành 80% - 90% thời gian để nghĩ ra các tính năng chưa ai từng làm (giờ nghĩ lại thì thấy phải có lý do người ta mới không làm) hay những tính năng, giao diện fancy và nghĩ rằng các giải pháp này sẽ mang lại impact tới người dùng và tiền về cho công ty. Lúc đó mình bị “solution centric” mọi người ơi ! Để rồi tính năng release xong rồi lại fail, không ai dùng rồi tự hỏi “Mình làm sai ở đâu?” câu trả lời là sai từ đầu 😂. Sau đó mình ngồi mò nghiên cứu để nhận diện cách làm sai và biết cách làm đúng, một cuốn sách mà mình recommend mọi người đọc là Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri, mình xin trích dẫn một đoạn ngắn của tác giả trong cuốn sách trên:

“The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce. When companies stop producing real value for the users, they begin to lose market share, allowing them to be disrupted. Companies can get out of the build trap by setting themselves up to develop intentional and robust product management practices.”

- Melissa Perri

Trong tuyên ngôn Agile có nhấn mạnh rằng “Hiểu rõ vấn đề quan trọng hơn suy nghĩ về giải pháp”.

“Understanding the problem over thinking of solutions”.

- Agile Product Manifesto

Giải thích đơn giản lại là:

Product Discovery nghĩa là đi tìm những gì tạo ra giá trị.
Product Delivery nghĩa là tạo ra những thứ có giá trị.

Discovery không phải là “kim bài miễn tử" hay sẽ đảm bảo 100% chúng ta biết chính xác điều gì tạo ra giá trị nhưng nó cung cấp những bài học kinh nghiệm giúp tăng cơ hội thành công. Bên cạnh đó, khám phá sản phẩm còn giảm thiểu nguy cơ phát triển các tính năng vô nghĩa và giảm thiểu các tổn thương không đáng có.

Và Delivery càng nhiều, viết càng nhiều code không có nghĩa là đội tạo ra nhiều giá trị hơn mà chúng ta cần xác định được cái quan trọng để xây.

Khi xây dựng một sản phẩm có rất nhiều thứ không chắc chắn nếu như hầu hết các ý tưởng của chúng ta không hiệu quả, chúng ta cần liên tục đầu tư thời gian để hiểu người dùng và thử nghiệm các ý tưởng khác nhau. Đó là lý do tại sao việc chú trọng đúng mức vào khám phá sản phẩm (Discovery) là rất quan trọng.

“The hard reality is that product strategy doesn’t happen in the solution space.”

- Teressa Torres

Thế nào là Product Delivery hiệu quả?

Như mình đã đề cập trong bài Discovery và Delivery là hai hoạt động liên tục, phụ thuộc lẫn nhau và xảy ra song song. Cả hai diễn ra đồng thời để đảm bảo sự linh hoạt, học hỏi liên tục và tạo ra sản phẩm đáp ứng tốt nhất nhu cầu của người dùng.

Product Discovery không đơn thuần là đầu vào cho Delivery và chúng ta cũng không nên xem Delivery chỉ là một giai đoạn sau khi hoàn thành Discovery vì điều này sẽ tạo hiệu ứng Waterfall khiến chúng ta xem đây là hai giai đoạn tách rời nhau, bỏ lỡ các cơ hội để học hỏi từ người dùng trong suốt quá trình phát triển và điều chỉnh sản phẩm và kìm hãm sự linh hoạt của nhóm.

Mình và team thường nói Discovery là khoảng thời gian vui nhất, mọi người dào dạt ý tưởng, thực hiện phân tích và testing cùng nhau nhưng tới khi Delivery thì mới là lúc cuộc chơi thật sự bắt đầu. Thử nghiệm thành công với một nhóm nhỏ không có nghĩa cả thị trường sẽ nói “I do” với chúng ta. Nên việc giữ mindset học hỏi liên tục là điều rất quan trọng.

Ở đây mình sẽ tổng hợp những điều để có được một quá trình Delivery thành công từ quá trình làm việc thực tế của mình, từ case study của các anh/chị đồng nghiệp và cũng từ các tác giả uy tín.

Ra mắt sản phẩm hoặc tính năng thường xuyên

Vòng đời phát hành càng ngắn, quá trình học hỏi càng nhanh. Chúng ta cần hiểu rõ tình huống cụ thể của mình. Chúng ta không thể đột ngột chuyển từ chu kỳ phát hành 3 tháng sang hàng ngày. Nhưng release vào các chu kỳ ngắn hơn như hàng tháng, 2 tuần, hàng tuần là điều khả thi. Cho đến hiện tại, đội mình vẫn release trong 2 tuần hoặc 3 tuần để đảm bảo sự học hỏi liên tục.

Đo lường kết quả

Cố gắng không phỏng đoán về impact của bản phát hành tới người dùng và tổ chức, hãy lập ra các chỉ số để đo lương sức khoẻ sản phẩm và ngồi thảo luận lại cùng với nhóm. Mình hiểu và đồng cảm về việc chúng ta bị “fall in love” với những giải pháp mà chúng ta xây dựng nhưng mình đang phục vụ người dùng và mang lại giá trị cho công ty nên giữ tinh thần học hỏi liên tục sẽ cho ra được các kết quả khách quan.

Mở rộng dần quy mô sản phẩm

Quá trình Discovery là để giảm thiểu rủi ro xây dựng các giải pháp không mang lại giá trị dẫn đến hao tổn tiền bạc, nguồn lực, thời gian thì trong quá trình Delivery này chúng ta cũng cần đi nhẹ nhàng mở rộng từ từ và liên tục để người dùng quen thuộc và có thời gian đón nhận, thích nghi giải pháp mới. Cũng như giảm những tổn thương không đáng có như sẽ không bị mang tiếng xấu nếu giải pháp chưa tốt, chưa thỏa mãn người dùng, hoặc sẽ không bị bỏ ngỏ khi giải pháp còn quá mới và người dùng chưa có thời gian để thích nghi.

Key takeaways

Để tạo ra được một giải pháp/sản phẩm có giá trị với người dùng và mang lại giá trị cho tổ chức, hai hoạt động chính là Discovery và Delivery nên được thực hiện bởi một đội sản phẩm có khả năng cross-functional nhằm đảm bảo sự liền mạch thông tin, tính nhất quán trong quá trình thực thi và làm việc. Hơn nữa, để giảm thiểu các tổn thất không đáng có đội ngũ sản phẩm cần cân bằng giữa Discovery và Delivery. Cuối cùng, khi xây dựng sản phẩm ai cũng mong muốn sản phẩm mình được thị trường đón nhận do đó key words ở đây là Continuos Discovery, Continuos Delivery quan sát, thử nghiệm, học hỏi và cải thiện liên tục.

Thông tin về mình:

Mình là Ngọc Mai mình là Product Manager/Product Owner làm việc với nhiều dự án ở các domain khác nhau y tế, AI, E-commerce, Fintech, HRM, Fitness. Hiện tại, mình đang cộng tác với một nhóm để nghiên cứu về cách làm sản phẩm. Mình từng làm qua với các công ty khởi nghiệp và tập đoàn lớn của Việt Nam lẫn nước ngoài và ở các công ty này mình may mắn được đào tạo và làm việc trực tiếp với C-level. Mình học Quản trị Du lịch một background về business và không liên quan tí nào đến kỹ thuật hay khoa học máy tính gì cả nhưng mình lại có niềm đam mê là tạo ra một cái gì đó giải quyết được vấn đề của mọi người và được mọi người đón nhận và thế là sau vài lần cuộc đời đẩy đưa lại đẩy mình vào làm product 😁.