Là một PO/PM, điều quan trọng nhất bạn cần làm là tìm kiếm được “right things to build”, đó là kết quả của quá trình Product Discovery. Điều này là không hề đơn giản, bạn cần kỹ năng problem-solving đủ tốt. Tương ứng, vì Product Discovery là khâu khó nhất, mà PO/PM và stakeholder có thể bỏ qua hoặc làm sơ sài, sau đó quyết định làm một “idea" nào đó và tự an ủi mình rằng “fail fast, learn fast”.

Tuy nhiên, nhìn từ phía của công ty, nếu thất bại đó dẫn đến những rủi ro lớn, chi phí lớn (bao gồm chi phí cơ hội) thì bạn sẽ không được cho cơ hội để fail, kể cả bạn là junior hay senior. Mình đã từng đọc qua nhiều bản kế hoạch, hoặc những product requirement sơ sài, chưa thấu đáo trong nhiều use case, và còn chứa những rủi ro cho người dùng, ảnh hưởng đến tính năng khác. Ở đây, không thể lập luận “release to test” hoặc “fail fast learn fast” được. Ranh giới giữa “fail to learn” và một sự chuẩn bị sơ sài tương đối mong manh. Benjamin Franklin có câu nói nổi tiếng thế này: "By failing to prepare, you are preparing to fail.”, dịch ra tiếng Việt là "Thất bại trong chuẩn bị là đang chuẩn bị cho sự thất thất bại”.

Nghe có vẻ mâu thuẫn, nhưng thực ra cả 2 tư duy trên đều đúng trong ngữ cảnh riêng của nó nếu không bị lạm dụng. Trong câu “fail fast, learn fast”, chúng ta cần hiểu:

• Cần “learn" gì?

• Có nhất thiết phải “fail” để “learn” điều đó?

• Sau khi “fail”, “learn" như thế nào, learn như thế nào cho “fast”?

Cần “learn" gì?

Câu trả lời là những thứ chúng ta chưa biết, đã tìm hiểu kỹ rồi mà vẫn không thể có câu trả lời. Đó là những assumption, những hypothesis trong quá trình discovery. Một lần nữa, một sản phẩm, một tính năng cần bắt đầu từ một nhu cầu, một vấn đề nào đó của khách hàng, của người dùng. Trong quá trình đó, chúng ta có những assumption, những hypothesis mà cả nhóm chưa trả lời được, thì đó là điều chúng ta cần learn.

Có nhất thiết phải “fail” để “learn” điều đó?

Nếu sự thất bại đó không mang lại hậu quả nghiêm trọng (risk), và có thể triển khai một cách nhanh chóng (effort), thì fail cũng là một cách để learn.

Nhưng nếu không (thường là trường hợp này), đâu là cách nhanh nhất (effort), và hiệu quả nhất (risk) để learn? Ví dụ: Nghiên cứu thị trường, nghiên cứu đối thủ, nghiên cứu người dùng, xin lời khuyên từ người có kinh nghiệm, … Nếu những cách trên vẫn chưa cho chúng ta câu trả lời đầy đủ cho vấn đề bên trên, thì phần nào cũng cung cấp insight để chúng ta hiểu thêm về vấn đề, scope down những assumption, hypothesis mà chúng ta cần learn, từ đó, giảm hậu quả (risk) và công sức (effort) để fail. 

Vậy, không nhất thiết cứ phải fail để learn, hãy xác định rõ vấn đề cần learn và tìm cách tốt nhất để learn nó. Trong Product Management, khâu Product Discovery vẫn cần được thực hiện một cách chỉnh chu, đầy đủ chứ không phải vì khó mà bỏ qua, mà biện minh bằng “fail fast, learn fast”.

Sau khi “fail”, “learn" như thế nào, “learn" như thế nào cho “fast"?

1. Fail rồi, bạn đã learn chưa, đã fast chưa?

Một hiện tượng phổ biến mà mình thường thấy và đã trải qua. Sau khi một sản phẩm, một tính năng được released:

• Không đo đạc kết quả (hoặc thậm chí từ đầu còn không xác định rằng đâu là chỉ số thể hiện sản phẩm/tính năng được làm có thành công hay không)

• Đo kết quả xong, thấy tốt, cùng ăn mừng rồi làm sản phẩm/tính năng khác

• Đo kết quả xong, thấy không tốt, mặc kệ sản phẩm/tính năng đó hoặc cho rằng người dùng không cần rồi làm tính năng khác

• Đo kết quả xong, thấy không tốt, kill tính năng đó rồi làm tính năng khác

Bạn có thấy quen không? 

2. Xác định fail hay không?

Vậy, sau khi làm một sản phẩm, một tính năng, việc đo đạc kết quả (trước đó cần xác định metrics) là chuyện bắt buộc phải làm. Trong product development cycle framework, hoặc các framework phổ biến nào khác trong ngành Product Management này, bạn đều thấy việc “discover" là một quá trình lặp lại, sau khi release sản phẩm, chúng ta có insight mới để tiếp tục khám phá các vấn đề, cơ hội để tiếp tục tạo ra một sản phẩm mới có giá trị hơn.

3. Cho dù fail hay không, vẫn learn với thần chú “Why?”

Nếu không đạt kết quả như mong đợi, bạn cần tìm hiểu tại sao lại như thế? Có assumption/hypothesis nào trước đó chúng ta đã sai? Đây cũng chính là điều mà chúng ta cần learn từ đầu, điều mà chúng ta chưa biết. Khi trả lời được “Why?” bằng cả data insight lẫn customer/user insight, bạn sẽ tiếp tục phát hiện các vấn đề để tiếp tục giải quyết.

Nếu đạt kết quả tốt, bằng hoặc vượt mong đợi thì cũng cần tìm hiểu nguyên nhân, tìm kiếm cơ hội để làm tốt hơn nếu có thể. Chưa chắc rằng, đó đã là kết quả tốt nhất chúng ta có thể đạt được. Chưa chắc rằng, chỉ số kia tăng bằng hoặc vượt mong đợi là vì sản phẩm/tính năng mà chúng ta đã release, lỡ đâu vì một nguyên nhân nào khác từ thị trường, từ các hoạt động non-tech thì sao.

4. Learn như thế nào cho “fast"?

Mục tiêu của việc “learn” là tìm kiếm các vấn đề, nhu cầu, cơ hội để tiếp tục chỉnh sửa hoặc tạo ra sản phẩm, tính năng mới giá trị hơn. Vậy “fast” là khi bạn tìm được kết quả đó một cách hiệu quả nhất. Bạn không cần phải có một báo cáo đầy đủ, chỉnh chu, không cần tìm được đầy đủ tất cả các nguyên nhân, mà bất kỳ khi nào bạn tìm được các insight đó, có thể nhanh chóng đánh giá về impact và effort để quyết định làm gì tiếp theo, để tiếp tục learn.

Ở Đại học, mình may mắn gặp được những người Thầy có tâm và có tầm, trong đó, có hai câu nói của hai người Thầy (các bạn có thể Google tên của 2 Thầy để biết họ là ai) mà càng về sau mình càng thấm:

• Thầy Dương Nguyên Vũ, ở lớp CM101: “Khi tụi em thuyết trình, điều quan trọng là tụi em hiểu vấn đề mà tụi em đang trình bày, chứ không phải tụi em phải đi đứng như thế nào, bỏ tay ở đâu, …. Cái tụi em cần rèn là bên trong của tụi em, thì sự tự tin sẽ được toát ra một cách tự nhiên”.

• Thầy Trần Minh Triết (lớp gì mình quên rồi vì Thầy dạy mình khá nhiều lớp): “Cần luyện nội công trước, chiêu thức sau”. Khi Thầy nói về việc học Thuật toán, Cấu trúc dữ liệu và giải thuật, … để hiểu rõ bản chất trước khi vội vàng học về ngôn ngữ lập trình, các framework, công cụ.

TRẢI NGHIỆM THỰC TẾ

Sau này, công việc của mình cần trình bày rất nhiều, từ các buổi meeting ở công ty, cho đến các buổi sharing, training và rất nhiều buổi pitching. Khi mình hiểu rõ về người nghe và mục tiêu, sau đó chuẩn bị kỹ nội dung, mình thường làm tốt ở các buổi này. Đồng thời, khi hiểu rõ về nội dung mà mình trình bày, thì mình sẽ đủ tự tin, nói chuyện một cách tự nhiên.

Trong công việc Product Management, mình càng thấy nội công (mindset, các kỹ năng cơ bản), quan trọng hơn chiêu thức (framework, công cụ). Ví dụ:

• Có agile mindset (và influence được mọi người xung quanh về agile mindset) quan trọng hơn so với biết cách ứng dụng Scrum hoặc Kanban.

• Tư duy, kỹ năng problem solving, khả năng phân tích quan trọng hơn các framework như design thinking, double diamond, JTBD. Bởi vì mục tiêu của chúng cũng là tìm ra vấn đề của khách hàng, cung cấp một giải pháp có giá trị cho họ. 

• Data-driven mindset, biết cách đặt câu hỏi, các giả thuyết (hypothesis), và hiểu cấu trúc data, quan trọng hơn biết viết SQL.

• Result-oriented mindset quan trọng hơn các phương pháp để sắp xếp độ ưu tiên.

• Tư duy user-focused/customer-focused, đặt mình vào người dùng (be a user) quan trọng hơn biết cách vẽ empathy map, customer journey. 

• etc.

MƯỢN CHIÊU THỨC ĐỂ LUYỆN NỘI CÔNG

Ở trên, mình nói rằng nội công (tư duy, các kỹ năng cơ bản) quan trọng hơn chiêu thức (framework, các công cụ). Tuy nhiên, không phải ngày một ngày hai mà bạn có nội công đủ tốt. Vì yêu cầu của môi trường công việc, bạn cũng cần có một vài chiêu thức để áp dụng trước khi có “nội công thâm hậu”. Bạn có thể tích luỹ dần nội công bằng cách vừa học chiêu thức, vừa rèn nội công (thấy được các vấn đề khi áp dụng framework, hiểu bản chất/cơ chế của framework trong quá trình áp dụng). Ví dụ:

• Để bạn có agile mindset, bạn có thể được đặt vào một scrum team nhưng sau đó làm product “không agile cho lắm”, sau đó bạn nhận ra các bài học và dần hiểu hơn về agile.

• Bạn bắt đầu sản phẩm bằng một ý tưởng, không xác định rõ vấn đề của khách hàng cần giải quyết, hoặc bị khách hàng hay các stakeholder khác dẫn dắt theo giải pháp của họ. Hoặc bạn được hướng dẫn và sử dụng Design Thinking, JTBD, tin rằng nó thần kỳ lắm và áp dụng nó vào công việc. Cho đến khi tính năng được làm ra mà không có ai dùng hoặc không đạt được kết quả về business. Bạn sẽ được hỏi (hoặc tự hỏi): Tại sao? Và từ đó, dần dần có kỹ năng Problem Solving tốt hơn.

• Bạn sử dụng các phương pháp sắp xếp độ ưu tiên. Rồi sau đó sẽ tự thắc mắc hoặc được hỏi rằng tại sao A lại được ưu tiên hơn B, trong khi mọi người đều tin B có thể cho kết quả tốt hơn mà. Bạn có thể dựa vào những tiêu chí khác (ví dụ: thời gian cần làm A và B) để thuyết phục mọi người nên ưu tiên A hơn B. Từ đó, dần nhận ra rằng bản chất của các phương pháp sắp xếp độ ưu tiên cũng là để chọn ra các dự án có ROI (return on investment) cao nhất để làm, không nhất thiết phải áp dụng phương pháp nào đó quá cồng kềnh.

Có thể mượn chiêu thức để luyện nội công, tuy nhiên, nếu trong quá trình làm việc mà các bạn tin răm rắp theo chiêu thức, không liên tục “critical thinking”, nhìn ra vấn đề để tạo dựng cho mình một tư duy tốt, thì bạn sẽ dần trở thành một “công nhân sản phẩm”. Hi vọng các bạn có thể tìm ra một người sư phụ có tầm (sếp) và một môi trường tốt (công ty) để luyện nội công.

TRÁNH TẨU HOẢ NHẬP MA

Trường hợp bạn luyện quá nhiều chiêu thức khi nội công chưa đủ tốt, bạn dễ bị tẩu hoả nhập ma. Đọc nhiều, học nhiều là điều tốt, nhưng cần chắt lọc thông tin và biết cách áp dụng. Tránh fomo, học hết framework này đến framework khác, thấy cái gì hay cũng thử qua loa. Chúng ta cần hướng đến mục tiêu của sản phẩm và tìm cách nào đơn giản nhất để đạt được mục tiêu đó. 

Trước khi nói đến sự khác nhau giữa PO và PM, mình cần làm rõ từ “Manager” trong từ “Product Manager”.

Trên thị trường, từ “manager” ở trong từ Product Manager có 2 nghĩa:

• Công việc quản lý (1)

• Người quản lý (2)

Tất nhiên, nếu là một PM ở nghĩa thứ (2), thì bạn cũng đã từng trải qua một PM ở nghĩa thứ (1), hoặc là Product Owner, Product Lead.

Product Manager có quản lý Product Owner hay không?

Trên thực tế, PM quản lý PO là PM với từ Manager mang nghĩa là “Người quản lý” (2).

Nhiều bài viết trên LinkedIn, từ các Product Expert, lại cho rằng PM không quản lý PO, chỉ đơn giản là PM phụ trách và chịu trách nhiệm trên quy mô công việc lớn hơn, đó là PM với từ Manager mang nghĩa là “Công việc quản lý” (1).

Product Owner và Product Manager (1) khác gì?

Dưới đây là cách phân biệt mà rất nhiều trang và tổ chức sử dụng:

Product Owner (PO):

• Là người chịu trách nhiệm tối đa cho giá trị của sản phẩm.

• Làm việc trực tiếp với nhóm phát triển để thực hiện tầm nhìn cho sản phẩm.

• Quản lý backlog sản phẩm, sắp xếp thứ tự ưu tiên cho các tính năng dựa trên giá trị và mức độ quan trọng.

• Hợp tác với các bên liên quan như khách hàng, nhà thiết kế, kỹ sư để đảm bảo sản phẩm đáp ứng nhu cầu thị trường.

Product Manager (PM):

• Có trách nhiệm chiến lược và tầm nhìn cho sản phẩm.

• Nghiên cứu thị trường, xác định nhu cầu khách hàng và xác định cơ hội cho sản phẩm.

• Phát triển chiến lược sản phẩm bao gồm định vị, giá cả, kênh phân phối.

• Quản lý vòng đời sản phẩm từ giai đoạn ý tưởng đến khi ra mắt và sau khi ra mắt.

Cá nhân mình đồng ý một phần nhưng lại thấy những định nghĩa trên tương đối trừu tượng đối với những người mới tham gia ngành này. Hiểu đơn giản, Product Manager chịu trách nhiệm trên một phạm vi công việc lớn hơn so với Product Owner, đặc biệt là đi sâu vào business nhiều hơn. Tuỳ vào tính chất mỗi doanh nghiệp, tuỳ vào phần mà bạn phụ trách thì công việc của PM có thể overlap với Strategy, Business, Operation, hay Marketing.

Tuy nhiên, có một phần mình không đồng ý, cần nhấn mạnh rằng, cả hai, PO hay PM, đều quản lý toàn bộ vòng đời phát triển của sản phẩm. PO vẫn trực tiếp làm việc với khách hàng, người dùng và business stakeholders chứ không phải chỉ có designer và team dev. PO vẫn làm Product Discovery chứ không chỉ quản lý Product Backlog ở trong một Scrum Team.

Năm 2020, khi ứng tuyển vào Chợ Tốt, mình thấy các trang tuyển dụng của Chợ Tốt ghi tuyển Product Owner, nhưng sau tham gia vị trí và công việc chính xác của mình là Product Manager và toàn bộ Product Department không có một PO nào cả. Lý do mà Chợ Tốt đăng tuyển như vậy là sợ ứng viên nhầm lẫn rằng công ty đang tuyển một “manager” - “người quản lý”.

Xét về kỹ năng và phạm vi công việc, Product Manager tất nhiên cần có đầy đủ năng lực của một PO. Ngoài ra, cần có kỹ năng, kiến thức sâu hơn về business của sản phẩm mà người đó phụ trách.

Ở bên dưới, hình bên trái là hình mình từng thấy ở một vài viết so sánh giữa PM, PO và BA. Nhưng mình biết rằng các bạn Business (Strategy, BA, Operation, Marketing, …) có rất nhiều kiến thức, kỹ năng và công việc khác mà PM/PO không làm được nên đổi sang hình ở bên phải. (Lưu ý: Độ lớn của các hình, độ lớn của vùng overlap chỉ là ngẫu nhiên, không thể hiện ý nghĩa gì khác)

Một vài Career Ladder trên thực tế của ngành Product Management

Trên thực tế,

Ở nhiều doanh nghiệp, đặc biệt là startup thì một bạn Product Owner cũng có thể có phạm vi công việc lớn như một Product Manager.

Ở nhiều doanh nghiệp, có vị trí Product Executive, được quản lý bởi Product Lead, Product Lead được quản lý bởi Product Manager.

Các công ty có các career ladder khác nhau

• Product Lead ở công ty A sang công ty B có thể về lại vị trí Sr. Product Owner/Manager và ngược lại.

• Product Director ở công ty sang công ty B có thể là Product Manager và ngược lại.

Dựa vào sản phẩm của doanh nghiệp, cấu trúc các phòng ban chức năng, chuyên môn và năng lực của các thành viên mà công ty có thể có mong muốn trên mỗi ứng viên khác nhau. Ví dụ:

• Có công ty mong muốn một bạn PM với sự chủ động và luôn chịu trách nhiệm cao nhất ở phạm vi công việc lớn nhất, dẫn dắt các thành viên ở các phòng ban khác thực hiện dự án.

• Có công ty mong muốn một bạn PO với năng lực phân tích tốt, trực tiếp thực thi việc phân tích data và người dùng (không có sự hỗ trợ của BA/DA, …) để hỗ trợ một Leader của phòng ban khác

• Có công ty mong muốn một bạn PO/PM đủ năng lực dẫn dắt cả team dev để deliver được sản phẩm

• …

• Nếu trả lời rằng “PO/PM là người chịu trách nhiệm cho thành công của sản phẩm. Họ làm việc với nhiều bộ phận khác nhau để xác định tầm nhìn, phát triển chiến lược và quản lý vòng đời sản phẩm.” thì nghe quá trừu tượng,

• Nếu trả lời rằng “PO/PM là CEO của sản phẩm” thì nghe hơi đao to búa lớn,

• Nếu liệt kê công việc, kỹ năng thì quá nhiều vì scope of work quá rộng

Bài viết hay video về “Product Management là gì? Product Manager/Owner làm gì?” đã có rất nhiều rồi, nên mình không lặp lại nội dung đó nữa. Hôm nay, mình muốn chia sẻ với các bạn một góc nhìn đơn giản hơn về chủ đề này và nếu làm được thì mình tin các bạn sẽ thành công trong công việc Product Management.

Trong từ Product Manager/Owner, có 2 từ. Thứ nhất là Product, thứ hai là Manager/Owner.

Product

PRODUCT ở đây không phải chỉ là phần mềm, mà còn là các quy trình, tài nguyên, … liên quan đến nó, với mục tiêu cuối cùng là mang lại giá trị cho khách hàng. Ví dụ:

• Nếu bạn làm sản phẩm cho một công ty giao nhận thương mại điện tử, thì các quy trình liên quan, SOP (Standard operating procedure) của shipper, hoạt động thực tế ở bưu cục giao nhận, hoạt động tại kho sorting, … cũng là một phần của sản phẩm của bạn. Tuy không trực tiếp quản lý và vận hành, nhưng bạn cần hiểu rõ và luôn nghĩ về giá trị cuối cùng mà tổng thể sản phẩm của bạn cung cấp cho khách hàng.

• Nếu bạn làm sản phẩm cho bãi giữ xe, thì thiết kế và hoạt động của các thiết bị phần cứng liên quan cũng là một phần của sản phẩm.

• Nếu bạn làm phần mềm quản lý cho một bệnh viện thì sản phẩm của bạn bao gồm từ lúc khách hàng đến bốc số cho đến lúc khám bệnh, chữa bệnh, chi trả viện phí, hồ sơ bảo hiểm, quản lý bệnh án và cả các dịch vụ sau đó. 

Tóm lại, PRODUCT ở đây là tất cả những gì mang lại giá trị cuối cùng cho khách hàng chứ không phải chỉ là phần mềm. Với tư duy này, bạn sẽ luôn liên kết phần mềm mà bạn làm ra với các thực thể xung quanh để hướng đến giá trị cuối cho khách hàng, tức là hướng đến sự thành công của sản phẩm.

Manager/Owner

Tiếp theo, từ MANAGER/OWNER, ở đây mang nghĩa bạn là người quản lý, chịu trách nhiệm cho sản phẩm đó. Các bạn có thể đã đọc được đâu đó rằng “PM/PO là CEO của sản phẩm", câu này không mang nghĩa rằng PM/PO có quyền quyết định toàn bộ trên sản phẩm, mà nó thể hiện độ rộng công việc và trách nhiệm của một PM/PO đến sản phẩm.

Tại sao điều này lại quan trọng? Mình từng gặp PM/PO với cách làm việc như sau:

• Khi team tech hỏi rằng “Chúng ta làm tính năng này để làm gì?” thì PM/PO trả lời rằng “Team business yêu cầu làm tính năng này.”

• Khi team biz hỏi về tình trạng của một cái bug khá nghiêm trọng chưa được sửa, thì PM/PO trả lời rằng “Đã báo với anh A (Tech Lead) rồi.” và không có thông tin gì thêm. Sau đó team biz phải tự liên hệ với anh A để trao đổi lại và hỏi tiến độ xử lý. 

• Khi có một sự cố về hệ thống xảy ra, PM/PO bảo rằng: “Đó là vấn đề của Tech" và sau đó chỉ đợi cho sự cố được xử lý hoàn tất. 

Đây là các ví dụ có thật cho thấy một tư duy về ownership rất có vấn đề mà PM/PO cần tránh. Với vai trò là một PM/PO, bạn cần hiểu rõ vấn đề, mục tiêu của sản phẩm, tính năng hay một dự án nào đó cần team làm. Thông thường, team biz sẽ đưa ra các yêu cầu về tính năng, và nhiệm vụ của PM/PO là cần hiểu được vì sao họ cần tính năng đó, khách hàng hay chính họ đang gặp vấn đề gì, nguyên nhân do đâu, tính năng ban đầu họ yêu cầu có giải quyết được vấn đề đó hay không (thường là không, hoặc dư, hoặc thiếu, hoặc không phải giải pháp tốt nhất), nếu không thì bạn đưa ra giải pháp như thế nào để đạt được problem-solution-fit. Từ đó, nếu có ai hỏi về tính năng đó thì chính bạn là người trả lời một cách mạch lạc và chặt chẽ về nó thay vì hỏi lại người yêu cầu. Để làm được điều đó không hề dễ, tuy nhiên, với tư duy “ownership" thì ít nhất bạn đã biết được rằng bạn cần làm như vậy.

Tóm lại

Product Owner/Manager chịu trách nhiệm cho thành công của sản phẩm, mang lại giá trị cho khách hàng và doanh nghiệp.

Tại sao mình để hai từ “giỏi” và “biết làm product” trong ngoặc kép?

• “biết làm product”: Năm 2019, mình được anh H - CPO của một công ty lớn phỏng vấn (thời điểm đó công ty rất hot vì sẵn sàng trả lương cao để tuyển nhân sự), anh H cũng là Founder của nhiều startup thành công. Để thuyết phục mình tham gia công ty, anh H bảo rằng: “Trên thị trường, phần đông PO/PM hiện tại không biết làm product, nếu về đây thì em sẽ biết làm product chuyên nghiệp.”

  Thời điểm đó mình hoài nghi thông tin này, vì tin rằng “biết làm product” đâu có khó, mình và team vẫn release sản phẩm bình thường, khách hàng vẫn dùng mà. Tuy nhiên, cho đến bây giờ thì phần nào mình lại đồng ý với anh H. Với hàng chục (xấp xỉ hàng trăm) PO/PM mà mình đã làm chung, phỏng vấn hay mentor thì mình nhận ra không phải PO/PM nào cũng “biết làm product”. Lỗi sai phổ biến nhất là “bắt đầu từ ý tưởng” (chính mình cũng từng mắc phải). Chi tiết hơn, mình sẽ chia sẻ ở các bài viết trên trang ProUp này.

• “giỏi”: Nếu bạn muốn trở thành một Product Owner/Product Manager, bạn hoàn toàn có thể tìm kiếm được nhiều bài viết, video, hay tài liệu trên mạng để học. Ở trang ProUp này, ngoài những kiến thức, kỹ năng đó, mình còn chia sẻ những lầm tưởng, những lỗi sai phổ biến của PO/PM từ kinh nghiệm thực tế khi đi làm, tuyển dụng, coach hay mentor cho các bạn PO/PM và cả những thứ mình học được từ các anh chị khác. Tin rằng với kiến thức - trải nghiệm - kinh nghiệm đó, mình có thể giúp các bạn trở thành những Product Manager “giỏi”.

Đây sẽ là trang master, tổng hợp tất cả các bài viết của ProUp theo đầu mục lớn, để các bạn dễ dàng tìm kiếm những kiến thức, kỹ năng và kinh nghiệm cần thiết của một Product Manager.

Tổng quan về ngành nghề Product Management

• Product Management - Liệu mình có phù hợp? - coming soon.

• Product Manager và Product Owner khác nhau như thế nào?

• Bạn là Product Manager nào? - coming soon.

• Tính cách và năng lực tạo nên một PM giỏi. - coming soon.

• Product Management - Career path. - coming soon.

Học gì để làm Product Management?

• Sinh viên muốn làm Product, hãy thử đi thi Khởi nghiệp!

• Học gì để làm Product Management? - coming soon.

• Học Tech, làm Product? - coming soon.

• Học Non-Tech, làm Product? - coming soon.

• …

Bức tranh tổng quan về Product Management và các kỹ năng cần thiết

• Product Development Cycle Framework - Tổng quan bức tranh Product Management

• Problem Solving - Những lỗi sai phổ biến

• Problem Solving - 101 - coming soon.

• Prioritization - Khó mà dễ

• Prioritization - Dễ mà khó

• Product Manager/Owner - Ownership mindset

• Task management - Manage yourself, manage your team - coming soon.

Strategic Planning

• Bắt đầu một sản phẩm, một tính năng, một dự án từ đâu?

• Roadmapping - Xây dựng kế hoạch để đạt được mục tiêu

• Prioritization - Khó mà dễ

• Prioritization - Dễ mà khó

• …

Product Discovery

• Problem Solving - Những lỗi sai phổ biến

• Problem solving

• Design thinking

• Objective & Success metric: Kim chỉ nam của sản phẩm - coming soon.

• Measurement - coming soon.

• …

Product Delivery

• Product Requirements Template và Những điểm cần lưu ý - coming soon.

• Agile/Scrum - Phần 1: Agile là gì? Agile giúp gì cho chúng ta?

• Agile/Scrum - Phần 2: Scrum - Phương pháp Agile được áp dụng phổ biến nhất

• Agile/Scrum - Phần 3: Problem Solving trong Scrum

• Measurement - coming soon.

• …

People Skills

• Stakeholder/Expectation Management - coming soon.

• Leadership - Product Owner/Manager - Bạn là leader từ ngày đầu - coming soon.

• …

Chuyển ngành?

• Từ BA thành PM? - coming soon.

• Từ QA/QC/QE thành PM? - coming soon.

• Từ Dev thành PM? - coming soon.

• Từ UI/UX Designer thành PM? - coming soon.

• Từ Biz, MKT thành PM? - coming soon.

• …

Nếu các bạn quan tâm đến bài viết nào ở trên, hoặc muốn mình chia sẻ thêm về chủ đề nào đó, thì có thể bình luận ở dưới bài viết này nhé 🥰

Trong một video về Product Management (tham khảo tại đây), mình có chia sẻ về khung năng lực (competency framework) của một Product Manager. Trong đó, có chia thành 3 nhóm năng lực chính:

• Product Development Process

• People Skills

• Domain Knowledge

Với mỗi nhóm năng lực kể trên, có rất nhiều kiến thức, kỹ năng và kinh nghiệm mình muốn chia sẻ. Trong bài viết này, mình sẽ đưa ra một bức tranh chung cho nhóm năng lực thứ nhất: Product Development Process, để các bạn hình dung được tổng quan công việc của một Product Manager sẽ như thế nào.

Product Development Cycle Framework

Tổng quan

Strategic Planning

Vào đầu năm, công ty cùng các phòng ban (business, marketing, tài chính, vận hành, …) đều đưa ra các mục tiêu và kế hoạch tổng quan trong năm, không ngoại lệ đối với team Product Management.

Ở mức độ tổng quan này, team Product cần xác định được Mục tiêu sản phẩm (Product objectives) dựa vào Mục tiêu kinh doanh (Business objectives), bằng các hoạt động như nghiên cứu thị trường, phân tích đổi thủ cạnh tranh, đánh giá và sắp xếp độ ưu tiên, xác định các mục tiêu, xác định nguồn lực (nhân sự, ngân sách), và lập kế hoạch hoạt động hàng năm (AOP Planning).

Sau đó, mỗi quý, mỗi tháng, Product Team lại tiếp tục xây dựng Product Roadmap dựa trên các Mục tiêu kể trên, cũng như các cập nhật mới nhất về Customer Insight, Data Insight và Strategic Insight (tham khảo Bắt đầu một sản phẩm, một tính năng, một dự án từ đâu).

Kết quả của công việc này là một kế hoạch với những mục tiêu cụ thể và những dự án cụ thể được làm với return on investment cao nhất.

Bài viết về roadmapping (cách xây dựng roadmap) sẽ được đăng tải sớm, các bạn theo dõi nhé!

Discovery & Delivery

Ở phần Product Discovery và Product Delivery này, nhiều bạn có thể đã biết đến các khái niệm như Design Thinking hay Double Diamond Model. Trong phần này, bạn có thể sử dụng framework hay model nào cũng được, nhưng nhìn chung, nó đều là quá trình giải quyết vấn đề (problem-solving) bằng cách hiểu thật rõ vấn đề đang cần được giải quyết, đưa ra giải pháp sao cho problem-solution-fit. Từ đó tiến hành xây dựng, triển khai và đo đạc kết quả xem vấn đề ban đầu đã được giải quyết hay chưa.

Product Discovery và Product Delivery sẽ bao gồm nhiều bước tạo thành một vòng lặp liên tục. Bởi vì để giải quyết một vấn đề, đạt được mục tiêu, không dễ dàng thành công ngay ở giải pháp đầu tiên. Thậm chí, chính vấn đề hay mục tiêu ban đầu còn có thể không đúng.

Ở bước thứ thứ nhất, chúng ta cần xác định được vấn đề, nhu cầu của khách hàng, người dùng, dựa trên customer insight, data insight và market insight. Từ đó xác định được mục tiêu và các chỉ số cần đo đạc trong quá trình xây dựng và vận hành sản phẩm. Sau đó, trải qua 7749 bước, sản phẩm được released, thì bước cuối là đo đạc các chỉ số đã đề ra, để xem chúng ta có đạt được mục tiêu hay không.

👉 Nếu có, thì có vấn đề, cơ hội nào khác, có bài học gì không và cần làm gì tiếp theo?

👉 Nếu không, thì tại sao lại chưa đạt được kết quả đó, những suy đoán, lập luận, insight ban đầu có vấn đề gì, cần làm gì tiếp theo để đạt được mục tiêu, hoặc thậm chí có đổi mục tiêu hay không?

Có thể thấy, từ bước cuối cùng này, lại quay lại bước đầu tiên để xác định vấn đề cần giải quyết.

Ở bài viết này, mình chỉ dừng ở bức tranh tổng quan của Product Development Cycle Framework. Các kiến thức, kỹ năng và kinh nghiệm cần thiết của các bước chi tiết sẽ được chia sẻ ở các bài viết sau.

Ở phần trước, chúng ta đã tìm hiểu về Scrum. Trong đó có chia sẻ về vai trò của PO/PM trong scrum team cũng như các sự kiện của scrum. Vậy, kỹ năng Problem Solving cần thiết đối với một PO/PM trong scrum như thế nào?

Vai trò xác định “right things to build”

Như trong bài viết về Scrum, vai trò lớn nhất của PO trong scrum team là xác định “right things to build”. “Right thing” ở đây là những tính năng, những cải tiến, những sản phẩm giúp khách hàng, người dùng giải quyết một vấn đề gì đó của họ đồng thời mang lại giá trị cho doanh nghiệp. Hơn nữa, những thay đổi đó mang lại giá trị cao nhất, tối đa hoá giá trị của sản phẩm nhờ vào công việc của scrum team trong một thời gian nhất định (Return on investment), thông qua việc sắp xếp độ ưu tiên (Prioritization).

Để làm được điều này, PO/PM cần có kỹ năng giải quyết vấn đề, cần biết đào sâu nguyên nhân gốc rễ của vấn đề để đưa ra một giải pháp phù hợp, problem-solution-fit.

Ở bài viết đầu tiên của ProUp, mình đã chia sẻ Những lỗi sai phổ biến nhất của PO/PM và các stakeholder liên quan khi xác định những dự án, tính năng, sản phẩm cần làm (What) mà không dựa vào ngữ cảnh, vấn đề và nguyên nhân gốc rễ của vấn đề (Why), lại bắt đầu từ ý tưởng, giải pháp.

Đã đọc qua hàng trăm PRD, lỗi sai phổ biến nhất mà mình thường đọc được là:

• “Vấn đề là đang thiếu tính năng A”

• “Mục tiêu là xây dựng tính năng A”

• “Tính năng A sẽ giúp người dùng hài lòng hơn”

Một lần nữa, PO/PM cần trả lời được thật rõ ràng: “Khách hàng, người dùng đang gặp vấn đề gì? Tại sao?”, “Khi giải quyết vấn đề đó, khách hàng, người dùng sẽ đạt được điều gì, công ty sẽ đạt được điều gì? Dựa vào chỉ số nào để biết vấn đề đã được giải quyết?”

Để biết thêm chi tiết, các bạn có thể đọc thêm bài viết Bắt đầu một sản phẩm, một tính năng, một dự án từ đâu?

Là một PO/PM, bạn cần chia sẻ được với scrum team mục tiêu của sản phẩm, trong sự kiện Sprint Grooming, bạn cần chia sẻ được lý do vì sao scrum team cần làm những công việc nào đó. Bởi vậy, kỹ năng problem solving là rất quan trọng để bạn hoàn thành công việc của một PO/PM, cũng như có cách giao tiếp hiệu quả với team.

Vai trò điều phối hoạt động của scrum team

Trong scrum team, PO/PM không quản lý, không lãnh đạo con người, mà quản lý sản phẩm. Tuy nhiên, để quản lý được sản phẩm, nhiều hoạt động của scrum team yêu cầu PO/PM đứng vai trò điều phối.

Mình sẽ kể một câu chuyện để thấy vì sao khi ở vai trò điều phối, bạn cần có kỹ năng giải quyết vấn đề tốt.

Ở một scrum team mình đã từng làm việc, có một anh Back-end Engineer giỏi, tốt nghiệp chương trình Kỹ sư Tài năng của Đại học Bách khoa TPHCM. Tuy nhiên, anh này ít nói chuyện với mọi người, chỉ làm việc một mình và thường rất khó khăn để trình bày về một điều gì đó cho mọi người hiểu.

Trong một buổi Sprint Retrospective, anh này có đưa ra một ý kiến rằng “Chúng ta nên giao tiếp với nhau nhiều hơn”. Ban đầu, mọi người khá ngạc nhiên và vui vì một người ít giao tiếp với cả team nhất lại đưa ra ý kiến rằng cả team nên giao tiếp với nhau nhiều hơn. Đến đây, nếu là bạn, với mục tiêu sau khi Retro sẽ có những “actionable tasks” thì bạn sẽ làm gì? Scrum master của team đã ghi lại rằng “Cả team nên giao tiếp với nhau nhiều hơn.” và kết thúc vấn đề.

Đến đây, mình mới hỏi lại rằng: “Trong sprint vừa rồi, có chuyện gì mà anh nghĩ rằng mọi người nên giao tiếp với nhau nhiều hơn?”. Sau một hồi đào sâu mới hiểu được vấn đề là API mà anh này làm ra không tích hợp được với phần giao diện và logic mà team Mobile đã làm, bởi vì hai bên đã không thống nhất với nhau về technical design trước đó, đến lúc mỗi bên làm xong thì không tích hợp được, phải họp lại và chỉnh sửa API. Sau đó, team đưa ra giải pháp là cần tuân thủ quy trình mà Engineering Department đã đưa ra trước đó, cần có technical design trước khi bắt đầu các task.

Qua câu chuyện này, bạn có thể thấy việc “cần có technical design trước khi dev” và việc “cần giao tiếp với nhau nhiều hơn” là hai giải pháp hoàn toàn khác nhau, việc giao tiếp nhiều hơn không giúp team đảm bảo rằng API tích hợp được với phần giao diện và logic mà team Mobile đã làm.

Ở vai trò của một PO/PM, bạn có thể tìm hiểu rõ ngữ cảnh, vấn đề xảy ra và nguyên nhân của nó trong suốt quá trình làm việc với scrum team, để cùng nhau đưa ra các cách làm việc, các giải pháp phù hợp để giải quyết được vấn đề.

Vậy, Scrum là gì?

Từ “scrum” được lấy cảm hứng từ môn bóng bầu dục, khi mà cả đội tập hợp thành một đội hình gọi là scrum để cùng nhau đưa bóng về phía trước.

Trong việc phát triển sản phẩm (phần mềm),  Scrum như một cách để hoàn thành công việc theo nhóm, theo từng phần nhỏ, với các vòng lặp thử nghiệm và phản hồi liên tục trong quá trình phát triển để tăng dần giá trị của sản phẩm. Scrum cung cấp framework và cách thức thực hiện để tối ưu quy trình làm việc.

Để làm việc theo scrum framework, cần có nhóm scrum (scrum team), bao gồm Product Owner, Scrum Master và Developers, mỗi vị trí có một trách nhiệm cụ thể riêng, sẽ được giới thiệu trong phần sau. Scrum team tham gia vào 5 sự kiện (scrum events) trong mỗi sprint, để tạo ra các “tạo tác" (scrum artifacts).

Các vai trò trong một scrum - Scrum Team

Trong một scrum team, có ba vai trò: Product Owner, Developers, và Scrum Master.

1. Product Owner - “Build the right thing”

• Vai trò: Như tiêu đề, PO có trách nhiệm xác định “right thing to build”. Vậy, như thế nào là “right thing”? Đó là những tính năng, những cải tiến, những sản phẩm giúp khách hàng, người dùng giải quyết một vấn đề gì đó của họ đồng thời mang lại giá trị cho doanh nghiệp. Hơn nữa, những thay đổi đó mang lại giá trị cao nhất, tối đa hoá giá trị của sản phẩm nhờ vào công việc của scrum team trong một thời gian nhất định (Return on investment). Để đạt được điều đó, PO cần làm các công việc dưới đây:

• Công việc:

  • Xác định (cùng với các stakeholders khác) và truyền đạt rõ ràng Mục tiêu sản phẩm

  • Tạo và truyền đạt rõ ràng các công việc trong Product Backlog. (Product Backlog: Sẽ được chia sẻ thêm ở phần dưới)

  • Sắp xếp (theo độ ưu tiên) các công việc trong Product Backlog. (Tham khảo thêm các phương pháp sắp xếp độ ưu tiên tại đây)

  • Đảm bảo rằng Product Backlog minh bạch, rõ ràng và dễ hiểu

Các công việc trên với mục tiêu xác định trách nhiệm của PO trong một Scrum team, không có nghĩa rằng đây là toàn bộ công việc của PO. Trong Product Development Cycle, đây chỉ là một phần công việc nhỏ của PO trong giai đoạn Product Delivery cùng team Tech. Tổng thể công việc của PO trong Product Development Cycle sẽ được chia sẻ ở bài viết sau.

2. Developers- “Build the thing right”

• Vai trò: là đội ngũ trực tiếp làm ra sản phẩm một cách đúng nhất với đặc tả từ PO. Điều này không có nghĩa rằng Developer sẽ chỉ nghe và làm đúng chính xác yêu cầu từ PO. Cả scrum team, bao gồm cả developer đều cần nhìn đến “mục tiêu của sản phẩm”, xem xét giải pháp mà PO đưa ra có giúp đạt được mục tiêu đó hay không, đặt ra những câu hỏi, gợi ý để làm rõ hoặc thậm chí thay đổi đặc tả.

• Công việc:

  • Lập kế hoạch cho mỗi Sprint

  • Phát triển sản phẩm, tuân thủ “Definition of Done”

  • Điều chỉnh kế hoạch mỗi ngày để hướng tới Mục tiêu Sprint (Sprint Goal)

Tương tự như PO, đây chỉ là những công việc của Developer trong cách làm việc theo mô hình Scrum. Ngoài ra, Developer còn rất nhiều công việc chuyên môn khác, để ngoài việc “build the thing right” thì còn đảm bảo hiệu suất, tính mở rộng, …

3. Scrum Master - “Build the thing fast”

• Vai trò: Scrum master giúp Scrum team làm việc hiệu quả  bằng cách tuân thủ các nguyên lý, các kỹ thuật và quy tắc của Scrum. Scrum Master không phải là người quản lý của Nhóm mà là một lãnh đạo theo phong cách phục vụ (Servant Leader). Scrum Master làm tất cả những gì trong thẩm quyền phục vụ Product Owner, Developer, và Tổ chức đi đến thành công, bao gồm cả việc huấn luyện và cố vấn cho nhóm hay các cá nhân trong Scrum team.

• Công việc:

  • Huấn luyện các thành viên trong nhóm về cách tự quản lý và làm việc nhóm

  • Tập trung vào việc tạo ra các Increments có giá trị cao đáp ứng “Definition of Done”

  • Loại bỏ các trở ngại, các vấn đề đối với tiến độ của Nhóm Scrum

  • Đảm bảo rằng tất cả các sự kiện Scrum diễn ra hiệu quả

  • Giúp PO tìm các kỹ thuật để xác định Mục tiêu Sản phẩm và quản lý Product Backlog hiệu quả

  • …

4. Kiêm nhiệm

Cá nhân mình từng chứng kiến hoặc trải nghiệm việc một scrum team bị thiếu đi vai trò của PO hoặc Scrum Master (không thể thiếu Developers). Sẽ có người nói rằng việc thiếu đi PO hoặc SM thì một scrum team sẽ không hoàn thiện và gặp nhiều vấn đề, cũng có người nói rằng việc thiếu đi PO hoặc SM không làm ảnh hưởng đến kết quả công việc của họ, một developer có thể đóng vai trò của một PO, một PO hoặc developer có thể đóng vai trò của một SM.

Quay lại, Agile ngoài là một phương pháp, thì còn là một lối tư duy, Scrum là một framework (khung) chứ không phải một process (quy trình), do đó, một tổ chức có thể áp dụng sao cho phù hợp và hiệu quả.

Với những trải nghiệm cá nhân của mình, việc một scrum team thiếu đi một trong hai vai trò trên, PO hoặc SM, thì scrum team đó sẽ gặp nhiều vấn đề. Một PO/PM, vai trò quan trọng nhất của họ là xác định “right thing to build”, để làm được điều đó thì cần kỹ năng problem-solving rất tốt, tránh việc bắt đầu bằng một giải pháp (start with a solution). Còn SM, có thể coi là vai trò điều phối, tổ chức hoạt động của một scrum team, họ có thể hỗ trợ cùng lúc nhiều team ở các hoạt động scrum, còn khi thiếu đi thì khi đi sâu vào công việc chuyên môn, PO và Developer có thể sẽ dần quên đi các nguyên tắc cơ bản của Agile, các quy tắc của scrum.

Các “tạo tác” trong scrum - Scrum artifacts

1. Product Backlog

Là một danh sách các công việc cần làm để cải tiến sản phẩm, được sắp xếp theo độ ưu tiên. Đây là nguồn công việc duy nhất của một scrum team (*)

(*) Trong quá trình phát triển sản phẩm, làm việc với nhiều stakeholders, có thể có các yêu cầu qua email, qua chat, qua các buổi họp, qua nói miệng, vân vân.

Để đảm bảo đó là “right thing to build” và các vai trò trong scrum team (hoặc cả các stakeholders khác) biết về công việc đó, thì nó cần được tổng hợp (consolidate) về một nguồn duy nhất (centralized).

Hoạt động Product Backlog Refinement với mục tiêu chia nhỏ, thêm/xoá/sửa, làm rõ các công việc trong Product Backlog, với mô tả rõ ràng, chi tiết, công việc được sắp xếp thứ tự và ước lượng độ lớn.

2. Sprint Backlog

Sprint Backlog, ngoài là những công việc trong Product Backlog được chọn ra để làm trong một sprint (What) thì nó còn bao gồm Sprint Goal (Why) và kế hoạch để tăng trưởng sản phẩm (increment) (How).

Sprint Backlog là một kế hoạch (How), một bức tranh thể hiện các công việc cần hoàn thành trong sprint (What) để đạt được mục tiêu (Why). Do đó, nó cần được cập nhật thường xuyên, ít nhất là hàng ngày (trong Daily Standup) để mọi người cùng nắm được tiến trình (progress) của scrum team.

Sprint Goal: Mục tiêu của sprint không phải là làm hết tất cả những công việc đã được lập kế hoạch trong sprint đó, mà là kết quả của công việc đó mang lại về sản phẩm, về giá trị cho người dùng, khách hàng và doanh nghiệp. Sprint Goal là điều mà cả team cần luôn nhớ trong suốt sprint, để khi có điều gì có thể thay đổi thì mọi người có thể trao đổi, thương lượng dựa trên mục tiêu đó.

3. Increment

Increment là phiên bản hoàn thiện của sản phẩm sau mỗi Sprint, với mục tiêu là tạo ra giá trị cho khách hàng thông qua việc cung cấp các tính năng có thể sử dụng. Increment phải hoàn thiện và có thể chạy được, cho phép khách hàng hoặc bên liên quan kiểm tra và đánh giá. (**)

(**) Quay lại bài viết về Agile, một trong những vấn đề của các phương pháp phát triển phần mềm trước đó (ví dụ: Waterfall) là đến cuối cùng, khi cung cấp sản phẩm dùng được cho khách hàng, cho người dùng thì đó có thể không phải là cái mà họ cần. Scrum chia ra các sprint ngắn (1-4 tuần, thông thường là 2 tuần) với mục tiêu nhận feedback liên tục từ khách hàng, từ người dùng. Do đó, việc “increment phải hoàn thiện và có thể chạy được” là cần thiết để đảm bảo nhận được những feedback rõ ràng nhất từ khách hàng, từ người dùng.

4. Definition of Done

Một task được gọi là “Done”, được gọi là một phần của Increment, đóng góp vào Sprint Goal khi nó thoả mãn “Định nghĩa hoàn thành - Definition of Done (DoD)”.

DoD còn là căn cứ, là khái niệm để các thành viên trong scrum team trao đổi xuyên suốt quá trình phát triển sản phẩm, từ việc làm rõ ràng một yêu cầu trong Product Backlog, cho đến xác định các tiêu chuẩn hay kịch bản kiểm thử sản phẩm.

Các sự kiện trong scrum - Scrum events

1. Sprint Grooming

Theo scrum.org thì không có scrum event này, nó sẽ là một phần của Sprint Planning (kéo dài tối đa 8 tiếng cho sprint 1 tháng và ít hơn nếu sprint ngắn hơn). Tuy nhiên, mình muốn tách nội dung này ra để nói rõ và chi tiết hơn về nó.

Người điều phối: Product Owner/Product Manager (với sự hỗ trợ của Scrum Master khi cần)

Hoạt động: Sprint Grooming được hiểu là buổi mà PO/PM trình bày cho cả scrum team về các dự án, các sản phẩm, các tính năng cần được làm. Đặc biệt lưu ý, PO/PM cần “Start with Why”, trình bày rõ ngữ cảnh, vấn đề của người dùng, khách hàng hay chính doanh nghiệp đang gặp phải; mục tiêu khi giải quyết vấn đề này; sau đó trình bày về giải pháp, PRD (Product Requirements Document). Trong khi hoặc sau khi trình bày, PO/PM cần giải đáp, làm rõ thắc mắc của scrum team, ghi nhận feedback hoặc những đề xuất của team để cải thiện trước khi vào buổi Sprint Planning. Từ đó, chia nhỏ ra thành các epic, user story, task, tương đương với hoạt động Product Backlog Refinement được chia sẻ ở trên.

Output: Kết thúc buổi Sprint Grooming, cả team cần có những tasks đã được chia nhỏ và làm rõ về scope of work, definition of done. Nếu có những thứ cần thay đổi (về PRD, về Design) hoặc Giải pháp kỹ thuật (Technical solution) thì cần có người phụ trách để hoàn thành các công việc này trước Sprint Planning.

Với những trải nghiệm của cá nhân, mình tin rằng nên tách Sprint Grooming ra, thậm chí trước Sprint Planning 1-3 ngày. Để nếu trong quá trình Grooming, sau khi nhận được các câu hỏi, feedback, đề xuất từ scrum team, thì PO/PM hoặc Tech Lead có thời gian để có những điều chỉnh về PRD, Technical solution. Team sẽ tiết kiệm thời gian hơn trong buổi sprint planning.

2. Sprint Planning

Người điều phối: Developer (Tech Lead) và/hoặc Product Owner/Product Manager (với sự hỗ trợ của Scrum Master khi cần)

Hoạt động: Từ buổi Sprint Grooming, scrum team đã có các user story, epic, và task được chia nhỏ, làm rõ và ước tính thời gian/công sức để hoàn thành. Ở buổi Sprint Planning này, cần trả lời 3 câu hỏi:

• Why? Mục tiêu của sprint này (Sprint Goal) là gì?

• What? Các công việc (task) nào cần được hoàn thành để đạt được mục tiêu đó? Đây là lúc mà các developer cùng cả team “kéo task” vào sprint, sao cho có thể đạt được Sprint Goal và cũng khả thi để hoàn thành được những task đó.

• How? Kế hoạch và cách thức để hoàn thành các task kể trên. Ví dụ: Back-end Engineer phải làm trước task A, B thì Mobile Engineer mới có thể làm task C được; Để làm được task D, cần một team khác hỗ trợ công việc E trước ngày thứ 3 của tuần tới.

Output: Mục tiêu của sprint, các công việc cần làm và kế hoạch để hoàn thành các công việc đó. Sau khi planning thì scrum team cũng “start sprint”, bắt đầu một sprint mới.

Trải nghiệm cá nhân: Nếu phần Sprint Grooming được làm hiệu quả, thì buổi Sprint Planning này thường diễn ra từ 1-2 tiếng, tuỳ vào số lượng thành viên của scrum team. Mình thường đề xuất buổi planning này diễn ra vào ngày thứ 3, thứ 4 hoặc thứ 5, để tránh việc mọi người thường nghỉ phép vào thứ 2 hoặc thứ 6 nhiều hơn (ghép với thứ 7, chủ nhật).

3. Daily Scrum

Người điều phối: Developer (Tech Lead) hoặc Scrum Master

Hoạt động: Dựa vào Why, What, How sau khi làm Sprint Planning, cả team sẽ hàng ngày chia sẻ về tiến độ, những khó khăn trong quá trình làm việc (nếu có) để cùng hướng đến việc đạt được Mục tiêu của sprint (Sprint Goal).

Output: Kế hoạch tiếp theo (có thể điều chỉnh so với kế hoạch ban đầu nếu cần) để đạt được Sprint Goal.

Trải nghiệm cá nhân: Hoạt động phổ biến trong Daily Scrum là các thành viên trả lời 3 câu hỏi: Hôm qua làm gì? Hôm nay làm gì? Có gặp khó khăn gì không? Việc lặp đi lặp lại các câu hỏi này trong nhiều ngày có thể khiến cả team chán Daily Scrum và/hoặc chỉ trả lời các câu hỏi trên mà quên mất việc cần làm là đạt được Mục tiêu của sprint, không phải chỉ báo cáo tiến độ và tìm cách giải quyết các khó khăn nếu có.

4. Sprint Review

Người điều phối: Developer (Tech Lead) hoặc Product Owner/Product Manager

Hoạt động: Chia sẻ về Sprint Goal và kết quả thực tế đạt được, demo các “increment” cho cả team cũng như các stakeholders khác và nhận feedback. Lưu ý: Daily Scrum không phải là buổi để báo cáo về tiến độ, thì Sprint Review càng không phải là buổi để báo cáo về tiến độ, mà cần tập trung vào Sprint Goal đã đề ra.

Output: Kết quả thực tế so với Sprint Goal cùng những feedback để tiếp tục cải thiện sản phẩm.

5. Sprint Retrospective

Người điều phối: Developer (Tech Lead) hoặc Scrum Master

Hoạt động: Nhìn lại sprint vừa trải qua, rút trích những bài học và kế hoạch để cải thiện hoạt động của scrum team. Có thể đi qua “Những thứ đã làm tốt”, “Những thứ làm chưa tốt, còn là vấn đề, cần cải thiện”, “Những việc nên làm để cải thiện”.

Output: Những “actionable tasks”, được giao cho một cá nhân phụ trách để triển khai nhằm đảo bảo hoạt động của scrum team sẽ hiệu quả hơn.

Trải nghiệm cá nhân:

• Có nhiều format (ví dụ: Drop - Add - Keep - Improve; Keep - Problem - Try), có nhiều tool (Bảng trắng, Parabol, Reetro, …) để thực hiện Retrospective. Bạn có thể chọn hình thức hoặc công cụ nào phù hợp với team của bạn, miễn sao cả team có thể đi sâu vào thảo luận để có những kế hoạch cải thiện hoạt động của team một cách rõ ràng.

• Nếu có nhiều “actionable tasks” cần làm để cải thiện hoạt động của team (đặc biệt thời gian đầu thường có nhiều vấn đề) thì cần sắp xếp độ ưu tiên (về mức độ nghiêm trọng, về tần suất lặp lại) để giải quyết từng vấn đề một cách hiệu quả.

• Kỹ năng problem-solving là rất quan trọng để điều phối hoạt động retro này (mình sẽ chia sẻ ở các bài viết tiếp theo).

Tổng kết

Scrum là framework được sử dụng phổ biến nhất trong các Agile Methodologies. Bài viết đã giới thiệu tổng quan về scrum, các vai trò, các khái niệm và các sự kiện trong scrum. Để bắt đầu áp dụng scrum, điều quan trọng nhất vẫn là tư duy agile, một scrum team hoạt động đúng với các kỹ thuật của scrum, mà không có tư duy agile, không “open to change” thì scrum sẽ biến thành một quy trình cứng nhắc, không mang lại hiệu quả. Không nhất thiết phải chuẩn bị đầy đủ các công cụ, có đầy đủ các vai trò trong scrum team, … để bắt đầu scrum, hãy thử - hiểu và thay đổi dần một cách agile.

Để có thể làm tốt vai trò của một PO/PM, trong mô hình làm việc nào, thì điều quan trọng nhất là làm sao để biết được “the right problems to solve", “the right things to build”, còn việc vận hành một scrum team với vai trò là một PO không quá phức tạp. Do đó, ban đầu mình không định viết về chủ đề này. Tuy nhiên, có vài lý do khiến mình thay đổi và quyết định viết về Agile/Scrum:

• Thứ nhất, trong quá trình hướng dẫn các bạn newbie, mình thấy rằng có nhiều bạn với background kinh tế, chưa biết trước về các mô hình phát triển phần mềm, cũng gặp nhiều khó khăn khi bắt đầu vận hành một scrum team. Chính mình với technical background, đã được học trước về Agile/Scrum ở Đại học, thì cũng mất khoảng 2-4 tuần để làm quen cách làm việc của một scrum team thực tế.

• Thứ hai, trước đây mình nghĩ việc áp dụng scrum đã phổ biến rồi, cho đến khi mình biết có nhiều doanh nghiệp công nghệ, hoặc có áp dụng công nghệ với đội ngũ hàng chục, hàng trăm kỹ sư vẫn đang sử dụng mô hình waterfall và đang gặp vấn đề với nó, cần chuyển đổi. Các bạn Product hay BA đã có kinh nghiệm ở vẫn chưa thể vận hành trơn tru một scrum team.

• Thứ ba, mình muốn trang proup.vn giúp các bạn trang bị đầy đủ các kiến thức, kỹ năng xuyên suốt để từ một newbie trở thành một PO/PM giỏi.

Bài viết này, mình sẽ đi từ lý thuyết (bạn có thể tìm kiếm ở nhiều nơi, nhưng có sẵn ở đây cũng tốt) cho đến thực tế, các trải nghiệm của mình trong quá trình vận hành nhiều scrum team, đặc biệt là khi làm các dự án cross-team.

Trước khi đi vào Scrum framework (một phương pháp Agile được sử dụng phổ biến nhất), mình cần đi qua về Agile methodologies.

Agile methodologies ra đời như thế nào?

Ngày nay, Agile/Scrum đã trở nên rất phổ biến và được nhiều doanh nghiệp công nghệ trên toàn cầu sử dụng. Các doanh nghiệp khi chuyển từ một mô hình phát triển phần mềm kiểu cũ (hoặc thậm chí không có quy trình) sang scrum (một framework thuộc Agile Methodology), thì câu hỏi đầu tiên cần trả lời là: “Tại sao? Agile/Scrum giúp được gì?”

Và câu trả lời cho câu hỏi trên cũng chính là lý do tại sao Agile Methodology ra đời. 

Câu chuyện ra đời của Agile bắt đầu vào những năm 1990 khi một nhóm các chuyên gia phát triển phần mềm nhận thấy rằng các phương pháp truyền thống không đáp ứng được nhu cầu của thị trường, đặc biệt là trong các dự án phần mềm có sự biến động lớn hoặc yêu cầu sự linh hoạt. Ngay khi bắt đầu dự án, rất khó để xác định được một sản phẩm, một phần mềm như thế nào sẽ là tốt trong dài hạn cả. Nếu áp dụng Waterfall, viết thật rõ và chính xác yêu cầu/đặc tả phần mềm thì sẽ tốn rất nhiều thời gian để nghiên cứu và thiết kế, nhưng sau đó vẫn phát sinh nhu cầu cần thay đổi trong quá trình phát triển cũng như sau khi sản phẩm được hoàn thành.

Vào năm 2001, 17 chuyên gia phần mềm tập trung tại Snowbird, Utah và họ đồng ý rằng vấn đề là các công ty đã quá tập trung vào việc lập kế hoạch và ghi chép quá mức về chu trình phát triển phần mềm của mình đến nỗi họ đánh mất điều gì thực sự quan trọng – làm hài lòng khách hàng của họ. Từ đó, "Manifesto for Agile Software Development" (Tuyên ngôn Agile) ra đời, tài liệu này đã thiết lập các nguyên tắc cơ bản của Agile, đặt trọng tâm vào việc tạo ra phần mềm linh hoạt, mục tiêu hướng tới hài lòng khách hàng, sự tương tác thường xuyên giữa các cá nhân và sự thích ứng với sự biến đổi.

Trong 17 chuyên gia, có vài nhân vật quan trọng với nhiều “khái niệm” phổ biến vẫn được dùng đến ngày nay:

• Kent Beck: Người đồng sáng lập Extreme Programming (XP), một trong những phương pháp phát triển phần mềm Agile đầu tiên.

• Ward Cunningham: Được biết đến với khái niệm "Wiki" và đã đóng góp quan trọng cho Agile thông qua việc giới thiệu các khái niệm quan trọng như "technical debt" (nợ kỹ thuật) và "refactoring" (tái cấu trúc).

• Martin Fowler: Nhà phát triển phần mềm nổi tiếng, đã góp phần quan trọng vào việc giới thiệu và phổ biến các nguyên tắc và phương pháp Agile.

• Alistair Cockburn: Người sáng lập Use Case, đã đóng góp vào Agile thông qua quan điểm về "project box” và sự cần thiết của sự tương tác giữa con người trong quá trình phát triển phần mềm.

• Jim Highsmith: Đồng sáng lập Agile Manifesto, đã đóng góp ý kiến về sự linh hoạt và sự phản hồi liên tục trong phát triển phần mềm.

Tuyên ngôn chỉ với 68 từ và tài liệu ngắn gọn, nhưng đã thay đổi quá trình phát triển phần mềm. Trong hơn 20 năm từ khi được tạo ra, tuyên ngôn và 12 nguyên tắc Agile đã được nhiều tổ chức áp dụng.

Tuyên ngôn Agile

Bốn giá trị cốt lõi của Agile là:

• Cá nhân và Tương tác hơn là Quy trình và Công cụ

• Phần mềm hoạt động hơn là Tài liệu chi tiết

• Hợp tác với Khách hàng hơn là Đàm phán Hợp đồng

• Phản ứng với Biến đổi hơn là Tuân theo Kế hoạch

Ở đây, cần lưu ý rằng các yếu tố bên phải cũng quan trọng, nhưng các yếu tố bên trái quan trọng hơn.

Một vài lầm tưởng từ tuyên ngôn này:

• “Quy trình là không quan trọng”: Tuyên ngôn Agile xác định rằng Cá nhân và tương tác quan trọng hơn Quy trình, không đồng nghĩa với Quy trình không quan trọng. Quy trình vẫn giúp cho công việc được thực hiện đồng nhất, đảm bảo kết quả và hiệu quả. 

• “Phần mềm chạy là được”: Tuyên ngôn Agile không cổ suý điều này. Sản phẩm không được thiết kế tốt, về cả UI/UX lẫn kiến trúc sẽ để lại nhiều vấn đề, nhiều “debt” cần giải quyết và khó khăn khi phát triển về sau. 

• “Tài liệu không quan trọng, product requirement (PRD) thiếu cũng không sao”: Tuyên ngôn Agile đề cao kết quả hơn so với việc viết tài liệu quá chi tiết (comprehensive), không đồng nghĩa với việc product requirement (PRD) không quan trọng. PRD vẫn cần thiết, không thể thiếu để trao đổi giữa các team (business, product, tech) và giúp team tech biết được cần phải phát triển sản phẩm như thế nào, chi tiết ra sao. Việc thiếu và thay đổi quá nhiều ảnh hưởng đến quá trình phải triển sản phẩm.

• “Cần phản ứng với biến đổi, PRD thay đổi là điều bình thường”: Tuyên ngôn Agile cổ vũ mọi người thích ứng với sự thay đổi, từ những thay đổi của thị trường, của khách hàng, hoặc team phát hiện ra các “insight” mới, … không đồng nghĩa với việc Product Owner có quyền thường xuyên thay đổi PRD, đặc biệt nếu lý do là chuẩn bị chưa đủ kỹ. 

12 nguyên tắc Agile

• Nguyên tắc 1: Ưu tiên cao nhất là làm hài lòng khách hàng thông qua việc bàn giao phần mềm/sản phẩm có giá trị trong thời gian sớm và liên tục.

• Nguyên tắc 2: Sẵn sàng cho những thay đổi - thậm chí những thay đổi này xuất hiện muộn. Quy trình Agile khai thác sự thay đổi này nhằm gia tăng tính cạnh tranh cho khách hàng.

• Nguyên tắc 3: Cung cấp phần mềm hoạt động được trong thời gian ngắn từ 1 vài tuần đến 1 vài tháng, càng ngắn càng được ưu tiên.

• Nguyên tắc 4: Người kinh doanh và đội ngũ phát triển phải làm việc cùng nhau mỗi ngày trong suốt dự án

• Nguyên tắc 5: Xây dựng dự án xung quanh những cá nhân có động lực. Cho họ môi trường làm việc thuận lợi và sự hỗ trợ cần thiết. Hãy có niềm tin rằng họ sẽ làm tốt công việc của mình.

• Nguyên tắc 6: Đối thoại trực tiếp mặt đối mặt là phương pháp hữu hiệu nhất trong việc truyền đạt thông tin.

• Nguyên tắc 7: Phần mềm chạy được là thước đo chính của tiến độ dự án.

• Nguyên tắc 8: Phát triển bền vững và duy trì việc phát triển liên tục.

• Nguyên tắc 9: Liên tục quan tâm đến kỹ thuật và thiết kế để tăng cường tính linh hoạt.

• Nguyên tắc 10: Đơn giản - nghệ thuật tối đa hóa số lượng công việc không làm - là điều cần thiết.

• Nguyên tắc 11: Các kiến trúc, yêu cầu và thiết kế tốt nhất được tạo nên từ các nhóm tự tổ chức.

• Nguyên tắc 12: Trong khoảng thời gian đều đặn, nhóm phản ánh về cách trở nên hiệu quả hơn, sau đó điều chỉnh cho phù hợp.

Vậy, Agile là gì, Agile Software Development là gì?

Agile là một triết lý, một khung tư duy để nhanh chóng thích ứng và phản hồi với thay đổi, từ đó đạt được thành công trong một môi trường liên tục biến động và không chắc chắn.

Triết lý Agile xuất phát từ ngành công nghệ và được mô tả bằng 4 giá trị và 12 nguyên lý cốt lõi trong Tuyên ngôn Agile (Manifesto for Agile Software Development). Tuy nhiên, triết lý Agile cho đến ngày nay không chỉ đã làm thay đổi cách làm việc trong công nghệ mà còn lan tỏa mạnh mẽ và thể hiện giá trị trong rất nhiều lĩnh vực như: Quản lý dự án (Agile Project Management), nhân sự (Agile HR và Agile People), hay Marketing (Agile Marketing) …

Tổng kết

Agile, ngoài là một phương pháp, thì còn là văn hoá, lối tư duy để giúp đội nhóm phối hợp làm việc mà  ưu tiên cao nhất là nhu cầu của khách hàng, là giá trị mà sản phẩm mang lại cho khách hàng, một cách nhanh nhất và liên tục.

Có vài framework thuộc phương pháp này, ví dụ như Extreme Programming (XP), Scrum, Kanban. Agile đưa ra 4 giá trị cốt lõi và 12 nguyên tắc, để các team tìm được cách làm việc phù hợp nhất. 

Phần 2 - Dễ mà khó: Những lỗi sai phổ biến và Nguyên tắc chung khi đánh giá độ ưu tiên

Đánh giá độ ưu tiên là trách nhiệm của ai

Mục tiêu của đánh giá độ ưu tiên là để chọn ra những sản phẩm, tính năng, dự án, … cần làm để giúp doanh nghiệp đạt được kết quả tốt nhất với nguồn lực và thời gian có giới hạn.

Để làm được điều đó, cần nhiều thông tin từ các team khác nhau, business, operation, marketing, product, tech. Tuy nhiên, vẫn cần một người, một team điều phối, thực thi việc đánh giá độ ưu tiên này. Đó chính là team Product. 

“Lỗi sai” phổ biến

Sau đâu là một vài “lỗi sai” phổ biến mà mình đã từng gặp

• “Idea của sếp nên cần được ưu tiên”. Mình từng gặp và cũng từng phỏng vấn một vài bạn PO/PM mà “idea của sếp” chính là thứ được ưu tiên làm trước, làm liền. Hoặc từng có BA (Business Analyst) đưa ra yêu cầu làm một tính năng và mong muốn được làm sớm với lý do là: “đó là idea của anh A, chị B”. Việc idea đó được ưu tiên có thể đúng, có thể sai. Idea có sếp có thể mang tính chiến lược (từ những nghiên cứu, quan sát, báo cáo, … nào đó), cũng có thể đang có một deadline nào đó liên quan, hoặc cũng có thể chỉ là một idea mà sếp nghĩ ra và gửi cho team. Với vai trò là PM/PO, bạn vẫn cần tìm hiểu, phân tích, đánh giá, không những để xem xét độ ưu tiên, mà còn để quay về xem vì sao có idea đó (why?), idea đó sinh ra để làm gì (for what?).

• Không thống nhất với các bên liên quan (misalignment), đặc biệt là PIC (person in charge), ở đây là PO/PM. Ví dụ trường hợp mình từng gặp: Team tech quyết định làm một dự án X mà PO không biết khi lên roadmap đầu quý, khi được hỏi thì lý do là: “Sếp Y giao deadline cho team vào cuối tháng này”. Ở đây, việc dự án đó cần làm và hoàn thành vào cuối tháng vẫn có thể đúng, để đạt được một mục tiêu nào đó, hoặc để thống nhất về thời gian với nhiều nhóm khác. Tuy nhiên, cho dù đó là một dự án về tech, thì cũng cần được đưa ra để đánh giá độ ưu tiên chung với các dự án khác, đồng thời để cho các stakeholder từ các team cùng biết về sự tồn tại của dự án đó để có kế hoạch hợp lý.

• Đây là quyền của PM/PO? Điều này không đúng. PM/PO sẽ là người cầm cân nảy mực, phân tích, đánh giá, … các initiatives từ tất cả stakeholders để đưa ra thứ tự ưu tiên hợp lý, chứ không phải là người quyết định 100%. Sau khi PO/PM đưa ra đề xuất, mọi người có quyền thắc mắc tại sao lại chọn dự án này, không phải dự án kia, hoặc đưa ra những lý do nên ưu tiên một dự án khác hơn. PO/PM có trách nhiệm đưa ra những tìm hiểu, phân tích, đánh giá, tại sao lại đề xuất như vậy và chỉnh sửa nếu cần thiết. Tuỳ vào công ty, tuỳ vào business, tùy vào vị trí mà người quyết định và chịu trách nhiệm cuối cùng là ai.

• PO/PM hoặc một người nào đó chỉ quyết định/đề xuất, không trao đổi thường xuyên trong quá trình prioritize và không thông báo (kèm lý do cụ thể) sau khi thực hiện xong việc sắp xếp độ ưu tiên. Ví dụ: Mình từng hỏi một bạn Business Analyst, tại sao lại sắp xếp roadmap như vậy, tại sao lại là dự án A chứ không phải dự án B? Cá nhân bạn BA này cũng tin rằng nên làm dự án A chứ ko phải dự án B, nhưng bạn lại trả lời mình là: “Không biết, PO quyết định như vậy”. Ở đây, PO cần chủ động chia sẻ cho các stakeholder về roadmap và lý do tại sao lại lựa chọn, sắp xếp như vậy. Đồng thời, bạn BA cũng nên đưa ra ý kiến của mình và hỏi lại PO lý do vì sao nếu chưa rõ.

• Chỉ dựa trên kết quả dự kiến. Mình đã từng chứng kiến PM/PO xây dựng roadmap chỉ dựa trên kết quả dự kiến. Giả sử những dự đoán đó là tương đối chính xác, thì điều này vẫn khiến cho roadmap đó thiếu đi các yếu tố khác, ví dụ như: Mức độ phức tạp của dự án (ease), khả năng thành công của dự án (confidence). Có trường hợp các dự án khác mặc dù rất nhỏ nhưng có thể tăng nhanh một chỉ số nào đó bị bỏ qua. Có trường hợp dự án đó cần được đầu tư trong 6 tháng để đem lại tác động lớn, nhưng sau 1-2 tháng chưa có kết quả tốt thì đã bị dừng.

• Chỉ xét đến việc “được gì” nếu làm, không xét đến việc “mất gì” nếu không làm. Điển hình là không xét đến các tech debt, những “món nợ” về kiến trúc, về kỹ thuật, mà trước đó team đã chủ động “mượn” để ưu tiên “release fast” hoặc do quá trình xây dựng thì những hệ thống cũ dần không còn phù hợp. Các tech debt nếu để lâu, không trả thì sẽ gây ra rất nhiều lỗi, cản trở quá trình phát triển tính năng mới trong tương lai.

• Ưu tiên dự án mới, bỏ qua các tính năng cũ, trong khi cải tiến các tính năng cũ thì thường có ROI (return on investment) cao hơn, bởi lẽ đã có sẵn, không tốn quá nhiều công sức (ease) để cải tiến và cũng đã có những learnings (confidence) sau khi release (xét cả công sức và thời gian của business và product).

• Đánh giá, sắp xếp độ ưu tiên khi chỉ mới có idea, chưa rõ về vấn đề cần giải quyết, tại sao cần tính năng đó, tính năng đó dùng để làm gì. Sau đó, vì nó được ưu tiên, cần làm sớm, nên để kịp với kế hoạch đặt ra, kịp develop thì làm discovery rất sơ sài, đi luôn đến thiết kế tính năng.

• “Dự án đã ở trong hàng chờ quá lâu, cần được ưu tiên” hoặc do áp lực từ các cá nhân, một dự án được nhắc lại quá nhiều lần khiến cho PO/PM bị biased. Nếu toàn bộ quá trình prioritization trước đó là hợp lý, thì một dự án đã ở trong hàng chờ quá lâu có nghĩa là nó không nên được ưu tiên, hoặc nguồn lực của công ty quá mỏng so với các mục tiêu cần đạt được. Mỗi lần đánh giá độ ưu tiên, thì tất cả các dự án đều được xem xét các tiêu chí một cách khách quan, việc một dự án đã ở trong hàng chờ quá lâu không đồng nghĩa với việc nó cần được ưu tiên để làm sớm. 

Một vài nguyên tắc cơ bản

Để tránh các lỗi sai trên, ngoài việc cần phân tích, sử dụng các framework để đánh giá một cách hợp lý, thì cũng cần có những nguyên tắc cơ bản khi sắp xếp độ ưu tiên và lập kế hoạch.

• Tối ưu nhưng không nhồi nhét: Cần dựa trên nguồn lực và thời gian, đồng thời có thể áp dụng các kỹ thuật để lập một kế hoạch tối ưu nhất, tuy nhiên không nhồi nhét. Tránh trường hợp sau khi phân tích, đánh giá độ ưu tiên rồi, dựa vào nguồn lực đã có để lên kế hoạch rồi vẫn muốn chọn thêm một vài dự án không được ưu tiên nữa, bởi vì cho dù có chọn thêm thì cũng không thực thi được (thông thường ở giai đoạn planning chúng ta thường underestimate sự phức tạp, thời gian, công sức cần thực hiện một dự án).

• Cần có cơ chế, quy trình để nhận nhu cầu từ các team, sau đó phân tích, đánh giá, lập kế hoạch và đồng bộ thông tin rõ ràng cho các stakeholders đó. Đảm bảo không bị thiếu, không bị misalignment trong quá trình lập kế hoạch. Phần này do team Product chịu trách nhiệm, nhưng mọi người đều có quyền được biết và hỏi lại nếu thấy chưa thuyết phục hoặc có ý kiến khác.

• Phân tích, đánh giá khách quan, đồng nhất. Có thể xem xét các trường hợp ngoại lệ với các lý do cụ thể. 

• Yêu cầu từ các stakeholder đều như nhau (idea từ sếp có thể được backup bởi những lý do mang tính chiến lược, cần tìm hiểu rõ nếu cần).

Tổng kết

Mục tiêu của đánh giá độ ưu tiên là để chọn ra những sản phẩm, tính năng, dự án, … cần làm để giúp doanh nghiệp đạt được kết quả tốt nhất với nguồn lực và thời gian có giới hạn. Do đó, tất cả mọi công việc, nguyên tắc, quy trình, trách nhiệm về việc đánh giá độ ưu tiên là để đạt được mục tiêu này. 

Tuy đã có các framework để phân tích và đánh giá độ ưu tiên, lập kế hoạch (DỄ), nhưng để áp dụng được thì cần hiểu được bản chất của nó và mục tiêu của công việc là gì (MÀ KHÓ).

Tuỳ vào quy mô, cách tổ chức, cách xây dựng chiến lược và lập kế hoạch của công ty mà bạn sẽ tham gia vào các công việc cần prioritization khác nhau. Bạn có thể nhận các câu hỏi tương tự như:

• “Năm nay, đâu là những dự án quan trọng để chúng ta có thể đạt được mục tiêu tăng trưởng?”

• “Tháng tới, quý tới chúng ta làm gì?”

• “Tại sao dự án này được làm, dự án kia lại không?”

• “Trong sprint này, team cần ưu tiên làm tính năng nào?”

• “Sprint đang chạy rồi, giờ có một yêu cầu mới, mình vẫn làm tiếp hay thay đổi như thế nào?”

• “Để xử lý lỗi này cần 2 ngày, có thể ảnh hưởng đến sprint goals, mình có cần sửa liền hay không?”

Prioritization là kỹ năng giúp bạn phần nào trả lời một cách thỏa đáng và hợp lý những câu hỏi trên. 

Mục tiêu của prioritization là để chọn ra những sản phẩm, tính năng, dự án, … cần làm để giúp doanh nghiệp đạt được kết quả tốt nhất với nguồn lực và thời gian có giới hạn. Để làm rõ chủ đề này, mình sẽ chia ra 2 nội dung chính:

Phần 1 - KHÓ MÀ DỄ: Cung cấp các phương pháp prioritization và những tình huống phù hợp để sử dụng.

Phần 2 - DỄ MÀ KHÓ: Tuy đã có các phương pháp prioritization, nhưng để sử dụng các phương pháp này cũng cần một khả năng phân tích sắc bén. Phần 2 chỉ ra những lỗi sai thường gặp, cũng như các nguyên tắc một cách thống nhất khi prioritization.

Các phương pháp đánh giá độ ưu tiên

Eisenhower Matrix

Eisenhower Matrix được sử dụng để nhanh chóng phân loại/sắp xếp thứ tự ưu tiên của các công việc cần làm, cho cả đội nhóm lẫn cá nhân. Nó cũng tương đối dễ để sử dụng và trao đổi. Bạn sẽ thường xuyên nghe các cụm từ “important and urgent”, “important but not urgent", “not important but urgent", và “not important and not urgent" khi trao đổi về priority thường ngày.

Impact (Value) - Effort Matrix

Impact - Effort Matrix được sử dụng để phân loại/sắp xếp thứ tự ưu tiên của các tasks (công việc) và các initiatives (sáng kiến).

Đây cũng là phương pháp được sử dụng tương đối phổ biến để nhanh chóng phân loại. Bạn sẽ thường xuyên nghe các cụm từ “high impact but low effort”, “high impact and high effort", “low impact and low effort", và “low impact but high effort" khi trao đổi về priority thường ngày. 

Ngoài ra, từ “quick wins" hay “low hanging fruits" cũng xuất phát từ đây, chỉ các công việc “high impact, low effort”.

Opportunity Score

Đúng như tên gọi, Opportunity Score được dùng để đánh giá và sắp xếp độ ưu tiên của các opportunities. Dựa trên hai tiêu chí: Importance và Satisfaction. Trong đó, điểm của một cơ hội, Opportunity score = Importance x (1 - Satisfaction). © The Lean Product Playbook by Dan Olsen

Kano Model

Kano Model được dùng để sắp xếp độ ưu tiên của các tính năng. Lưu ý, đánh giá dựa trên vấn đề mà tính năng đó giải quyết chứ không dựa vào giải pháp, thiết kế cụ thể như thế nào.

Risk vs. Reward

Risk vs. Reward được dùng để đánh giá, phân loại và sắp xếp độ ưu tiên của các initiatives (sáng kiến). Trong đó, những sáng kiến nào mang lại hiệu quả và ít rủi ro thì sẽ được ưu tiên, và ngược lại, sáng kiến nào rủi ro nhưng không nhìn thấy hiệu quả thì có thể bỏ qua.

(R)ICE Framework

ICE hay RICE Framework được sử dụng để sắp xếp độ ưu tiên dựa trên nhiều yếu tố. Trong đó có Reach (R), Impact (I), Confidence (C), Ease (E, hoặc Effort). Tuỳ ICE hay RICE để có xét đến Reach hay không.

Nếu E là Ease thì công thức là R x C x I x E, nếu E là Effort thì công thức là R x C x I / E.

Vì được cân nhắc trên nhiều yếu tố, nên ICE là một framework tương đối tổng quát. Có nhiều công việc (task), cải tiến (enhancement) mặc dù có impact (I) nhỏ, cải thiện được UX hay giúp người dùng đỡ bối rối ở một bước nào đó, tuy nhiên, lại có thể hoàn thành rất đơn giản (E) và mọi người rất tự tin (C) vào dự đoán về impact và effort đó, thì công việc đó vẫn có thể được ưu tiên để làm.

MoSCoW Method

Các ký tự M, S, C, W lần lượt là viết tắt của Must have, Should have, Could have, Won’t have. MoSCoW ngoài được dùng để phân loại các tasks thì còn thường xuyên được sử dụng để “scope down", “define minimal scope" khi làm sản phẩm.

Các trường hợp ngoại lệ

Các trường hợp ngoại lệ thường xuất hiện khi có ràng buộc (constraint) hoặc sự phụ thuộc (dependency) nào đó. Lúc này, PO/PM cần linh hoạt để xử lý và thống nhất với các stakeholders.

Ví dụ:

• Có một dự án để hỗ trợ cho chiến dịch truyền thông đầu năm học mới, cần được hoàn thành và release trước ngày sinh viên nhập học.

• Có một dự án với sự tham gia của nhiều team, mà tất cả phải cùng release một ngày mới được. 

• Một dự án được ưu tiên nhưng để làm được dự án đó thì cẩn trả nợ tech debt trước.

• Dự án A được ưu tiên cao hơn dự án B, dự án A cần Backend và Web, dự án B cần Back-end và Mobile (cả Android và iOS). Để hoàn thành dự án A thì Backend cần 8 ngày, trong khi để hoàn thành dự án B thì Backend cần 2 ngày. Vậy thì Back-end Engineer vẫn nên hoàn thành dự án B trước.

• …

Phương pháp nào được sử dụng phổ biến?

Cá nhân mình thường sử dụng chính 4 phương pháp: (R)ICE, Eisenhower Matrix, Impact - Effort Matrix và MoSCow. Trong đó:

• (R)ICE được sử dụng để nhanh chóng phân nhóm các initiatives khi xây dựng roadmap. Sau khi đã đánh giá, chấm điểm cho các dự án, mình lựa chọn được các items nên làm, từ đó, tiếp tục đánh giá thêm các ràng buộc khác (ví dụ: kế hoạch của business team, nguồn lực của tech, sự phụ thuộc của các dự án, …) để sắp xếp một roadmap hợp lý.

• Eisenhower Matrix để đánh giá công việc của cá nhân và các thành viên khác trong team. Mình sử dụng các cụm từ “important and urgent”, “important but not urgent”, “not important but urgent”, và “not important and not urgent” để nhanh chóng biết cần làm gì.

• Impact - Effort Matrix, có thể coi là một phiên bản tối giản của (R)ICE. Mình cũng sử dụng các cụm từ “high impact but low effort”, “high impact and high effort", “low impact and low effort", “low impact but high effort", “quick wins" và “low hanging fruits” để nhanh chóng đánh giá và trao đổi với các stakeholder về priority.

• MoSCoW được sử dụng để “scope down” hay “define minimal scope" khi làm một sản phẩm, một tính năng để “release fast, learn fast".

Tổng kết

Có thể dễ dàng nhận ra, các phương pháp prioritization là các framework để đánh giá dựa trên nhiều yếu tố. ví dụ: impact and effort; impact, confidence and ease; reach, impact, confidence and effort; importance and urgency; risk and reward; … Tùy vào tính chất, giai đoạn, quy mô, … của doanh nghiệp để quyết định xem đánh giá dựa trên yếu tố nào. Tuỳ vào mục đích để sử dụng mô hình nào cho đạt được kết quả (priority) một cách đơn giản nhất.

Tuy đọc qua thì có vẻ KHÓ, nhưng khi trải nghiệm một thời gian ngắn (vài tháng) là bạn có thể sử dụng thuần thục, và nói về priority như một bản năng (MÀ DỄ).

Câu trả lời chung nhất là xuất phát từ một vấn đề cần được giải quyết, nó có thể là một vấn đề mà người dùng đang gặp phải với sản phẩm của mình, có thể là một vấn đề người dùng đang gặp ở ngoài kia mà sản phẩm của mình chưa giải quyết, có thể là một vấn đề khiến cho kết quả kinh doanh không tốt, có thể là vấn đề từ thị trường, đối thủ, có thể là một yêu cầu về tài chính, luật lệ, …

Chung quy lại, thông thường, một sản phẩm, tính năng, một dự án được bắt đầu từ một trong 3 thứ sau: user insights, data insights hoặc strategic insights. Tuy bắt đầu từ một trong ba, nhưng bạn sẽ cần cả ba để validate một sản phẩm, một tính năng, một dự án có đáng làm hay không, mức độ ưu tiên như thế nào, làm với mục tiêu gì và làm như thế nào.

Bắt đầu từ User/Customer insights

Dấu hiệu và cách để có user/customer insights

Là một Product Owner/Product Manager, có thể bạn không lạ gì với việc một ngày đi làm thì nhận được feedback, báo lỗi, than phiền, … từ khách hàng, từ người dùng, từ đồng nghiệp về sản phẩm. Nó có thể đến từ những bình luận về sản phẩm của mình trên mạng xã hội, có thể là đánh giá 1-2 sao trên Apple Store/Google Play, có thể là một vài tickets từ team Chăm sóc khách hàng, có thể là feedback của khách hàng thông qua team Sales hoặc cho chính bạn, … Và đó là thời điểm mà bạn biết rằng cần phải làm gì đó (tất nhiên là vẫn cần discover, prioritize, ideate, … trừ trường hợp nó là critical bugs thì phải sửa ngay). Đây chính là xuất phát từ user insights.

Nhưng như thế này là chưa đủ, bởi vì các lý do sau:

• Phải thực sự gặp vấn đề lớn, khiến công việc nào đó của khách hàng gặp khó khăn, thì họ mới chủ động đi feedback với các bạn. Còn những bất tiện khác mà họ có thể vượt qua hoặc nguy hiểm hơn là không sử dụng sản phẩm của bạn nữa thì họ sẽ không cho bạn biết. 

• Nhóm power user (nhóm người dùng với mức độ engagement cao nhất) thường xuyên đưa ra feedback hơn so với nhóm casual user, core user. Và nếu chỉ nghe từ nhóm này thì sẽ bị bias với insights của riêng họ mà thôi.

Do đó, ngoài việc nhận feedback một cách thụ động, chúng ta cần phải chủ động get out of the building, thường xuyên nói chuyện (có mục tiêu và không có mục tiêu) với khách hàng để hiểu được những vấn đề mà họ gặp phải. 

Trong trường hợp sản phẩm chưa có gì cả, thì đây cũng là cách hữu hiệu nhất để xây dựng một sản phẩm có giá trị cho người dùng.

Validate user insight với data và strategy

Tuy nhiên, không phải cứ khách hàng phàn nàn thì mình sẽ làm theo ý họ. Bởi vì hai lý do: 

• Thứ nhất, có rất nhiều vấn đề khác nhau từ nhiều nhóm khách hàng khác nhau. Vì vậy sẽ rất khó để chúng ta có  đủ nguồn lực để xử lý tất cả; 

• Thứ hai, một vài khách hàng không đại diện cho toàn bộ khách hàng, chưa kể khách hàng thường “come with an idea”. 

Vậy, dựa vào đâu để phân tích, đánh giá vấn đề đó đang xảy ra với nhóm nào, lớn hay không, có nghiêm trọng không, ưu tiên xử lý theo thứ tự như thế nào, … hoặc thậm chí đó có phải là vấn đề thực sự hay không? Data và strategy sẽ giúp chúng ta phân tích, đánh giá và trả lời những câu hỏi đó.

Bắt đầu từ Data insights

Dấu hiệu và cách để có data insights

Với các sản phẩm công nghệ, chúng ta thường có những dashboard với các data, bảng biểu, biểu đồ, báo cáo được update liên tục với đầy đủ các chỉ số thể hiện từ kết quả kinh doanh cho đến performance của các sản phẩm, tính năng cụ thể hoặc thậm chí là số liệu của đối thủ. 

Tuỳ vào sự chuẩn bị và cách sử dụng data của mỗi công ty, mỗi sản phẩm mà cách làm có thể khác nhau. Tuy nhiên, một sản phẩm, tính năng, dự án, thường được bắt đầu từ data insights khi mà:

• Một (vài) chỉ số nào đó xuống thấp/lên cao bất thường (so với tuần trước, tháng trước hoặc cùng kỳ năm ngoái)

• Một (vài) chỉ số nào đó thấp hơn so với mục tiêu, kỳ vọng đặt ra

Đó là thời điểm mà chúng ta phát hiện ra một vấn đề đang cần giải quyết hoặc một cơ hội cần được khai thác.

Để có được data insights này, chúng ta cần xây dựng văn hoá, thói quen về sử dụng data, chuẩn bị đầy đủ các dashboard, báo cáo từ doanh thu, cho đến traffic, retention, … Hơn thế nữa, luôn đề cao việc đo đạc kết quả, phân tích đánh giá và cải tiến sản phẩm, tính năng sau release.

Validate data insight với user và strategy

Data insight cho chúng ta biết rằng có một vấn đề hoặc một cơ hội nào đó đang tồn tại, nhưng cụ thể vấn đề đó là gì, tại sao lại như vậy thì chưa xác định được. Chúng ta cần kết hợp với user insights, từ những insights chúng ta đã có trước đó hoặc chủ động nghiên cứu để biết vấn đề cụ thể đang tồn tại là gì và lý do tại sao. Nếu chúng ta có thể nhanh chóng đoán được lý do thì đó là kinh nghiệm, là những hiểu biết về khách hàng, về ngành mà chúng ta đã có, đó cũng chính là user/strategic insights. 

Bắt đầu từ Strategic insights

Dấu hiệu và cách để có strategic insights

• Năm 2020, trong đại dịch Covid-19, nhiều sản phẩm hoặc tính năng mới đã ra đời, có thể kể đến như Zalo Connect, kết nối người mua và người bán thực phẩm mà khoảng cách là tiêu chí quan trọng nhất. Data hay user không trigger cho Zalo làm điều đó, mà ở đây Zalo nhìn thấy một cơ hội, một vấn đề mới phát sinh cần được giải quyết.

• Là một PO/PM, có thể bạn sẽ nhận một dự án, sản phẩm nào đó từ các sếp đưa xuống (có thể kèm thêm nhiều lý do cho việc đó, một cơ hội nào đó từ thị trường chẳng hạn).

• Khi làm sản phẩm, chúng ta cần theo dõi đối thủ của mình đã, đang và sẽ làm gì, kết quả kinh doanh như thế nào, điểm mạnh, điểm yếu ra sao. Và có nhiều tính năng, sản phẩm cũng xuất phát từ đây để bắt kịp hoặc vượt xa họ. 

Đây là những dấu hiệu dễ thấy của việc bắt đầu một sản phẩm, một tính năng từ strategic insight. Và để luôn có được những strategic insights chất lượng, chúng ta cần liên tục update về thị trường, về các cơ hội, thời điểm và xu hướng mới. Thậm chí, chúng ta có thể xây dựng những hoạt động nghiên cứu thị trường chuyên nghiệp và thường xuyên. 

Validate strategic insight với user và data

Mình không ít lần chứng kiến hoặc trải nghiệm việc một PO/PM hoặc cả team không cảm thấy thuyết phục với một yêu cầu nào đó từ sếp khi nó xuất phát từ những strategic insights chung chung. 

Khi xuất phát từ một data insights, user insights, bạn có cơ sở rõ ràng hơn để xác định, phân tích và đánh giá vấn đề, còn từ strategic insights thì nó sẽ mờ hơn. Điều này cũng khá hiểu nhiên, bởi vì nếu nó cũng rõ ràng thì ai cũng làm được, công ty nào cũng làm được rồi. 

Do đó, cần sử dụng user insights (chủ động lẫn bị động) để xác định khách hàng là ai, họ gặp vấn đề gì và sử dụng data để xem vấn đề đó có xảy ra nhiều với tập user lớn hay không, … Và việc này cũng không mang mục đích là để mọi người tin hơn vào ý tưởng ban đầu, mà là để thực sự xác định được vấn đề, mục tiêu và hướng đi của sản phẩm, tính năng.

Khác

Ngoài ra, chúng ta còn có thể bắt đầu một tính năng, một dự án khi đó là yêu cầu để phù hợp với quy định của pháp luật, yêu cầu về tài chính, … Lúc này, chúng ta có thể dùng user insights, data insights để ước tính được tác động (tích cực và tiêu cực) lên sản phẩm, doanh nghiệp của mình. 

Hãy để lại bình luận nếu bạn có câu hỏi, feedback hoặc một câu chuyện nào muốn chia sẻ nhé!

• Thứ nhất, đây là kỹ năng được áp dụng được với hầu hết mọi công việc và cả trong cuộc sống. Khi làm Product Management hay Entrepreneurship, đây là kỹ năng bạn phải sử dụng hàng ngày, đến mức nó thành thói quen, thành bệnh nghề nghiệp. 

• Thứ hai, đây là kỹ năng cực kỳ quan trọng ảnh hưởng đến thành công hay thất bại của một Product Manager hay Entrepreneur. Mình thường nói là: “Một người “biết làm product" là một người phải có kỹ năng problem solving tốt.”, và không dễ tí nào để có được kỹ năng này, thuần thục nó, không dễ tí nào để “biết làm product”.

• Thứ ba, mỗi ngày, mình gặp rất nhiều những lầm tưởng, những lỗi sai cơ bản với kỹ năng này. Và chính bản thân mình, khi còn là sinh viên, đi thi Khởi nghiệp thì cũng gặp lỗi sai này và cố chấp với nó.

Do đó, mình tin rằng, chỉ cần xây dựng problem solving mindset tốt, công việc của bạn sẽ tốt hơn nhiều lần.

Với chủ đề này, bài đầu tiên mình muốn chia sẻ đó là Những sai lầm phổ biến liên quan đến Problem Solving.

Nghĩ rằng “có nhiều ý tưởng” là “problem solving” tốt

Mình đã từng phỏng vấn nhiều bạn nghĩ rằng bản thân là một good problem solver vì thường xuyên có nhiều ý tưởng, có nhiều giải pháp cho sản phẩm, cho team. Trong quá trình làm việc, mình cũng gặp nhiều bạn người thường xuyên ném ra rất nhiều ý tưởng về việc làm các tính năng mới cho sản phẩm và nghĩ rằng “công việc của Product Manager là suy nghĩ ra các ý tưởng, tính năng mới”. Và phổ biến hơn nữa là rất nhiều những dự án khởi nghiệp “bắt đầu từ ý tưởng” thay vì “bắt đầu từ vấn đề”. Điều này không sai, biết đâu, trong những ý tưởng đó có một ý tưởng gì đó thật đột phá, sáng tạo thì sao. Tuy nhiên, khi được hỏi chi tiết hơn về việc ý tưởng đó dùng để làm gì, giải quyết vấn đề gì, cho ai, không có ý tưởng đó thì họ bị gì, đã có ai cung cấp giải pháp cho vấn đề đó hay chưa và giải pháp đó còn tồn tại vấn đề gì … thì bí.

Cũng dễ hiểu vì những câu hỏi này rất khó và mất nhiều thời gian để trả lời được.

Albert Einstein có nói: “Nếu tôi có 1 giờ để giải quyết 1 vấn đề, tôi sẽ bỏ ra 55 phút để nghĩ về vấn đề, và 5 phút nghĩ về giải pháp.”

Bốc tách vấn đề, hiểu rõ về vấn đề và nguyên nhân cốt lõi, mới là điều cần làm để giải quyết vấn đề, chứ không phải là đưa ra giải pháp từ những thứ mình chỉ mới quan sát được.

Việc “bắt đầu từ giải pháp, ý tưởng” cũng là nguyên nhân dẫn đến các sai lầm phổ biến được kể ra tiếp theo đây.

“Em có một ý tưởng …”, “Em làm một cái sàn TMĐT …”, “Bên anh đang làm một cái app …”, “Anh cần một trang như facebook …”

Đâu đó, bạn có thể đã nghe những câu tương tự như thế này, và thường trong dấu 3 chấm đó là rất nhiều những giải pháp, những tính năng diệu kỳ nào đó. Nó có thể đến từ khách hàng, có thể đến từ một đội thi ở một cuộc thi khởi nghiệp nào đó, có thể đến từ các mentee, có thể đến từ đối tác, bạn bè, … 

Mình vừa phỏng vấn một bạn sinh viên, bạn này đạt giải ở hai cuộc thi khởi nghiệp (dừng ở Top 5 một cuộc thi cấp trường và top 30 ở một cuộc thi toàn quốc). Khi mình hỏi bạn làm gì thì bạn nói rằng “Em làm một sàn giao dịch B2B để kết nối các doanh nghiệp với nhau.” Khi được hỏi thêm rằng tại sao bạn làm dự án này, thì bạn chia sẻ rằng “Em thấy rằng các quán cafe họ dùng ống hút nhựa, không sử dụng các ống hút eco friendly, nên sàn B2B của em sẽ kết nối người bán là các đơn vị làm ống hút eco friendly với các doanh nghiệp F&B để các doanh nghiệp F&B sử dụng ống hút eco friendly trong quá trình kinh doanh”. Các doanh nghiệp F&B họ có thể đã biết đến ống hút thân thiện với môi trường rồi, và các đơn vị cung cấp ông hút cũng rất tích cực trong việc chào bán đến khách hàng của họ. Và nếu họ có quyết định mua, thì họ cũng rất dễ dàng để tìm kiếm nhà cung cấp, làm thủ tục và mua hàng. Vậy, các doanh nghiệp F&B có thực sự cần một sàn B2B e-commerce để biết đến, để mua các ống hút thân thiện với môi trường cho họ hay không? Có thể, các doanh nghiệp F&B không sử dụng ống hút này vì giá cả, vì nó mềm nhanh trong nước, …  Như vậy, bạn vừa đưa ra một giải pháp không đạt problem-solution fit.

Ngáo thuật ngữ, dùng dao mổ trâu để giết chim

Trong thời đại mà công nghệ phát triển, đi đâu cũng nghe “4.0” “chuyển đổi số" “trí tuệ nhân tạo" thì việc “làm một cái app", “làm một con AI", “tụi em làm blockchain”, “sử dụng AI, machine learning để …”, càng phổ biến. Bạn sẽ rất dễ để bắt gặp những cụm từ này trong các cuộc thi Khởi nghiệp (ở nhiều quy mô khác nhau), hay thậm chí ở chương trình Shark Tank.

Nếu các bạn có theo dõi Shark Tank, chắc bạn đã từng nghe đến cụm từ “ngáo thuật ngữ” từ Shark Bình. Trong tập có dự án “Bất động sản sạch”, Founder của dự án đã trình bày rằng công ty thể scale up rất tốt dựa trên “nền tảng công nghệ Big Data, Luật sư AI và Smart Contract” và đã phát triển sản phẩm dựa vào “hàng triệu thuật toán”. Theo như trải nghiệm và chia sẻ của Shark Bình ở trên sóng truyền hình, thì công nghệ của công ty này đơn giản là truy vấn các thông tin từ data sẵn có về quy hoạch và luật, không đến mức đao to búa lớn như các thuật ngữ mà các bạn sử dụng. Việc lạm dụng các thuật ngữ này không những không có hiệu quả mà còn phản tác dụng, cho thấy hiểu biết chưa đủ sâu về vấn đề. Ngoài ra, ở đây, công ty đang muốn giải quyết bài toán làm sao để định danh, truy vấn thông tin về một sản phẩm bất động sản, bài toán này cần nhất là dữ liệu quy hoạch chứ không phức tạp đến mức cần sử dụng các công nghệ bên trên.

(Không tìm được hình của Bất động sản sạch nên mình lấy hình của Dr.Expedia, điều này càng cho thấy hiện tượng này phổ biến)

“Vấn đề là đang thiếu …”

Đây là “problem statement" mà mình thường nghe trong quá trình đi làm từ team business, từ team marketing, từ team operation và cả từ các bạn Product Manager có nhiều năm kinh nghiệm. Trong dấu 3 chấm đó, sẽ là một solution, một giải pháp, “Vấn đề là đang thiếu solution này". Tức là, bằng một cách nào đó, bạn đó muốn có solution, và bạn nói rằng vấn đề là thiếu solution của bạn. Vậy câu hỏi đặt ngược lại là “solution A đó giải quyết vấn đề gì? cho ai? vấn đề đó tác động đến họ như thế nào?” hoặc nếu khó trả lời quá thì có câu hỏi dễ hơn “solution đó mang lại giá trị gì? cho ai? họ sẽ sử dụng, họ sẽ trả tiền cho nó chứ?”

“Trên thị trường chưa có ai làm như em cả, sản phẩm của tụi em là đầu tiên"

Đây là câu trả lời phổ biến khi các startup được hỏi về cạnh tranh kiểu: “Các bạn có gì khác biệt so với các đối thủ trên thị trường?”. Có nhiều startup thực sự sáng tạo thì đúng là như vậy, nhưng phần đông thì ngược lại, câu trả lời này đặt ra cho người nghe nhiều nghi vấn: “Tại sao chưa có ai làm?” “Vì sẽ không có ai dùng (không có giá trị)?” “Vì thị trường quá nhỏ?”, “Các bạn đã tìm hiểu kỹ chưa?”, … Tuy nhiên, một lỗi cơ bản ở đây là các bạn xác định không đúng đối thủ cạnh tranh, đối thủ cạnh tranh là các sản phẩm/dịch vụ giải quyết chung vấn đề mà bạn đang giải quyết, chứ không phải một sản phẩm/dịch vụ nào đó tương tự.

Chạy theo khách hàng: “Bên em có làm được … không?”. Phân biệt want và need

Nếu bạn nào từng tiếp xúc với khách hàng, có thể là cá nhân, có thể là doanh nghiệp, đặc biệt là những khách hàng có trả tiền, các bạn sẽ không lạ với câu nói này. Trong dấu 3 chấm đó vẫn là một solution nào đó, mà chính khách hàng nghĩ ra. Mình không chê trách gì khách hàng ở đây được, đó là lý do tại sao cần có Business Analyst, Product Manager, Product Analyst, … hoặc những công việc tương tự để tìm hiểu vấn đề, nhu cầu của khách hàng đằng sau câu nói đó. 

Ở công việc đầu tiên của mình sau khi mới tốt nghiệp Đại học, với một sản phẩm có sử dụng AI, computer vision, tuy có problem-solving mindset, nhưng lại háo thắng và thiếu sự khôn khéo, mình thường trả lời là “Được. Nhưng mà anh/chị cần cái đó để làm gì? Nếu anh chị cần giải quyết vấn đề A, thì em nghĩ là có giải pháp này …, còn nếu anh chị cần để giải quyết vấn đề B, thì em nghĩ là có giải pháp kia …”. Thay vì hỏi/quan sát cặn kẽ vấn để mà khách hàng đối mặt, thì mình phạm 2 lỗi ở đây: 

• Thứ nhất là khẳng định làm được để thể hiện cái tôi mặc dù không tin rằng solution đó giải quyết một nhu cầu nào đó của người dùng, và cũng chưa hiểu họ cần gì. 

• Thứ hai là assume rằng khách hàng đang gặp vấn đề A hoặc B từ phán đoán của cá nhân, khiến mình bị bias sau đó. 

Ngoài ra, mình còn quan sát được hai sai lầm khác trong trường hợp này nữa. 

• Mình từng thấy nhiều người chạy theo “want" và “solution" của khách hàng luôn, muốn gì làm đó, cho đến khi ra sản phẩm thì khách hàng không dùng vì không giải quyết được vấn đề gì của họ cả, rồi sinh ra bực tức là sao trước đó khách nói vậy mà giờ không phải vậy. 

• Trường hợp thứ hai là tự suy luận rằng khách hàng bị một vấn đề gì đó và đưa cho họ một giải pháp khác, hoặc thậm chí là một tính năng có sẵn, thuyết phục họ sử dụng, dẫn đến việc khách hàng không hài lòng và mình cũng chẳng biết vì sao. 

Là một Product Manager, một Entrepreneur, khi gặp câu hỏi này, mình cần tỉnh táo để tìm hiểu “Quá trình sử dụng/làm việc, anh chị gặp vấn đề gì? Anh chị hay ai trong doanh nghiệp của anh chị gặp vấn đề đó? Demo cho xem được không?”

Cũng với ngữ cảnh này, Henry Ford có một câu nói là:

“Khi tôi hỏi mọi người rằng họ muốn phương tiện đi lại của mình như thế nào? Họ nói với tôi rằng họ muốn một con ngựa chạy nhanh hơn.”

Nếu không nhìn vào need (di chuyển nhanh hơn) thay vì want (con ngựa chạy nhanh hơn), có thể đã không có Henry Ford là cha đẻ của ngành công nghiệp oto rồi.

Tổng kết

Good problem solver sẽ tập trung vào vấn đề, tìm kiếm và phân tích rõ các khía cạnh, nguyên nhân gốc rễ của vấn đề đó để đưa ra một giải pháp đơn giản và hiệu quả nhất thay vì “bắt đầu từ solution”.

Hãy để lại bình luận nếu bạn có câu hỏi, feedback hoặc một câu chuyện nào muốn chia sẻ nhé!