"Fail fast, learn fast" - Có nhất thiết phải fail?

Có thể bạn đã từng nghe qua cụm từ này “fail fast, learn fast”,  hoặc một vài câu tương tự như “fail to learn”, “dare to fail”, hoặc trong tiếng Việt của mình sẽ có những cụm từ như “rút kinh nghiệm”, “thất bại là mẹ thành công”. Trong JD của các vị trí fresher, intern, junior, cũng coi đây là “selling point” của công ty đối với ứng viên còn ít kinh nghiệm. Tất cả đều chỉ ra một tư duy và kinh nghiệm rất tốt: Học từ thất bại, từ trải nghiệm thực tế.

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”.

© quotescover.com

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.

Product Development Cycle Framework

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.