Kinh nghiệm khi đưa ra 1 quyết định về Product tồi

Tôi thường tự hỏi liệu tôi có bị đuối việc khi quyết định như vậy không.

Tôi thấy có rất ít product manager chia sẻ về thất bại của họ, điều này sẽ khiến những người mới lầm tưởng rằng nhũng PM khác làm việc rất tuyệt vời nhưng sự thật là họ luôn bị vướng phải các sai lầm suốt.

Câu chuyện này là về một quyết định tồi tệ khi làm sản phẩm tôi đã thực hiện khi còn làm PM của FreshBooks.

Nó chẳng phải là một trang sử thi về sự thất bại của một công ty, giống tiểu sử không liên quan của một nhà sáng lập nổi tiếng, nó giống một pha xử lí sản phẩm tồi tệ, không có gì đặc biệt hơn. Sự nghiệp của tôi vẫn sống sót nhưng kinh nghiệm đã dạy tôi phải chú ý tới những giả định của mình và làm cách nào mà bạn vẫn có thể sai kể cả khi bạn đang làm điều đúng đắn.

Thật dễ dàng khi biết được lí thuyết để trở thành 1 PM tốt, nhưng áp dụng kiên thức đó một cách kiên định, kỉ luật và khiêm tốn mới là phần khó.

Bối cảnh

FreshBook là sản phẩm kế toán của một công ty nhỏ, có nền tảng về dịch vụ. Khách hàng chủ yếu là các cơ quan, luật sư, nhà đất, v.v… chủ doanh nghiệp sẽ tính tiền khách hàng của họ dựa trên thời gian và cần theo dõi chi tiêu. Chúng ta sẽ gọi những người sử dụng này là “Owner – Chủ sở hữu” cho phần còn lại của bài viết.

Tần nhìn của FreshBook cho tới thời điểm này là một thế giới nơi chủ sở hữu không cần biết đến kế toán thì mới có thể điều hành doanh nghiệp.

Đối với team product, điều này có nghĩa là nếu chúng ta có thể chưng cất “kế toán” xuống các định nghĩa đơn giản mà chủ sở hữu đã biết ( như gửi hóa đơn) và thực hiện toàn bộ công việc kế toán phức tạp phía sau, chúng ta có thể giải quyết một vấn đề lớn bằng cách cho phép họ tập trung phát triển doanh nghiệp của mình mà không phải đụng đến sổ sách.

Vấn đề

Cho dù FreshBook đem lại cho họ rất nhiều lợi ích, nhưng chủ sở hữu vẫn phải nộp thuế chho chính quyền ít nhất một lần một năm. Bởi vì, đa số chủ ở hữu không có nhiều kinh nghiệm về tài chính, điều này có nghĩa họ phải thuê kế toán vào cuối năm để giúp họ hoàn thành và lưu trữ những tài liệu thuế đó.

Vấn đề xảy ra cho các chủ sở hữu là hầu hết tất cả các kế toán đều sử dụng Quickbooks và FreshBooks không thể tích hợp bởi vì các mẫu data không tương thích với nhau.

Giải pháp là các bảng kê. Các bảng kê là ngôn ngữ vũ trụ cho các kế toán. Công việc của team là chuyển dữ liệu của FreshBooks sang các bảng kê và làm chúng trở nên có thể chia sẻ được để các kế toán có thể nhập dữ liệu của FreshBooks sang QuickBooks và sử dụng.

Xác nhận khách hàng

Chúng tôi dành hàng tháng để chuyển dữ liệu sang các bảng kê, điều này rất phức tạp vì chúng tôi phải áp dụng nhiều nguyên lí kế toán cụ thể cho từng loại giao dịch tại FreshBook.

Tôi tình cờ lại từng là CPA nên cũng tự nhiên trở thành người thẩm định phần kế toán trong team.

Song song với việc xây dựng, chúng tôi dành nhiều thời gian kiểm chứng với cả chủ sở hữu và kế toán.

Với chủ sở hữu, chúng tôi kiểm chứng trải nghiệm người dùng khi xuất các bảng kê và chia sẻ với kế toán của họ. Chúng tôi rất nhanh chóng nhận ra rằng giải thích các bảng kê cho các chủ sở hữu chẳng khác gì giải thích code cho người không phải là lập trình viên vậy.

Vì vậy, chúng tôi quyết định làm sáng tỏ tất cả các định nghĩa của bảng kê từ chủ sở hữu và chỉ giải quyết chúng một cách cơ bản. Chủ sở hữu có thể tiếp tục chụp các hóa đơn và gửi như họ vẫn thường làm và các mục tạp chí vẫn sẽ xuất hiện khi họ cần.

Với các kế toán, chúng tôi xác nhận các nguyên tắc kế toán đang được áp dụng cho mỗi giao dịch FreshBooks. Tôi phải nói chuyện điện thoại với ít nhất một kế toán mỗi ngày trong nhiều tháng như chúng ta đã trải qua một số điều như sau:

Như mọi product team trong giai đoạn xây dựng sản phẩm, chúng tôi đã tạo ra hàng trăm quyết định nhỏ trong quá trình đó: Một vài cái đơn giản như đặt tên các loại chuyển đổi hay phức tạp hơn là team hỗ trợ của chúng tôi sẽ giải quyết các vấn đề của khách hàng mà không cần bằng cấp liên quan đến kế toán như thế nào.

Rồi một ngày, chúng tôi cần phải đưa ra một quyết định khó khăn: Ngày nào chúng ta nên dùng để tạo ra một bảng kê

Mọi chuyện kết thúc bằng việc tôi chọn sai, điều này dẫn đến sự thất bại của toàn bộ project.

Quyết định

“Brandon, chúng ta cần phải chọn ngày để lưu trữ mỗi bảng kê, chúng ta có nên:

1. Sử dụng ngày mà chủ sở hữu thường nhập các thông tin chi phí, hóa đơn, v.v.. hay
2. Sử dụng ngày mà chủ sở hữu sẽ tạo ra các thay đổi trên app

Các kĩ sư trong team hỏi tôi

Tôi sẽ nói rất kĩ trong phần tiếp theo để có thể hiểu rõ câu chuyện hơn.

Ngày tháng trong kế toán rất quan trọng cho việc tính toán thuê vì họ có thể xác định xem vài thứ có được tính hay không tính thuế trong năm, kể cả khi nộp cho chính quyền. Một ví dụ đơn giản là chi phí được tạo ra vào ngày 31/12/2016 sẽ được tính vào thuế 2016 nhưng nếu được tạo ra vào 1/1/2017 thì sẽ phải đợi đến năm tiếp theo mới được tính. Điều này có thể tạo nên tác động lớn lên nhà kinh doanh.

Sự phức tạp trong việc chọn ngày càng khó hơn khi FreshBooks cho phép chủ sỏ hữu edit ngày tháng bất kì lúc nào. Sau khi suy nghĩ, chúng tôi nhận ra rằng option 1 ( ngày chủ sở hữu nhập số liệu) có thể dẫn đến việc tình cờ gian lận thuế. Sau đây là bối cảnh:

1. Chủ sở hữu gửi bảng kê tới kế toán để lưu trữ số liệu năm 2015, bao gồm cả chi tiêu vào tháng 6/2015

2. Vào 2016, chủ sở hữu edit chi tiêu tương tự và đổi ngày sang tháng 2/2016. Sau đó, họ gửi các bảng kê 2016 tới kế toán của mình

Chúng ta đã nộp khoản chi tiêu giống nhau cho 2015 và 2016. Điều này rất tệ và về mặt kĩ thuật nó được xem là gian lận.

Khi nhận ra rằng quyết định này sẽ có nhiều nhánh lớn, tôi tập trung vào việc nói với các kế toán – khoảng hơn 30 người – về hoàn cảnh chính xác. Đa số họ đều nhấn mạnh về tầm quan trọng của việc không cho phép chủ sở hữu tình cờ tăng gấp đôi bất cứ chi phí nào, đặc biệt khi họ không có bất cứ nền tảng về tài chính nào.

Các cuộc đối thoại với kế toán nhanh chóng khiến chúng tôi loại bỏ phương án 1. Thay vào đó, chúng tôi nhanh chóng chuyển sang tập trung vào phương án 2 – sử dụng ngày ghi nhân các chuyển đổi

Đây là một cách tiếp cận trực quan đơn giản. Chủ sở hữu chỉ cần đi về năm họ ghi nhận chi tiêu, nhận thanh toán, v.v… và chúng tôi có thể sử dụng bất cứ ngày nào họ tạo ra chuyển đổi trên app là ngày của bảng kê. Chủ sở hữu không cần phải biết về tác động của ngày trên bảng kê – nó sẽ hoạt động bình thường.

Chúng ta sẽ lặp lại phần thứ 2 của bối cảnh gian lận với mô hình mới này.

2. Vào 2016, chủ sở hữu edit chi tiêu tương tự và đổi ngày sang tháng 2/2016. Sau đó, họ gửi các bảng kê 2016 tới kế toán của mình.

Vào thời điểm đó, điều này như 1 thắng lợi lớn. Chúng ta vẫn có khả năng thoát khỏi các vấn đề mà không cần phải dạy các chủ sở hữu các kiến thức kế toán. Chúng tôi quyết định chọn lựa chọn 2 và chuyển tới việc tạo ra thêm hàng trăm quyết định tiếp theo.

Vào tháng 12 – một tháng trước khi hầu hết các chủ sở hữu cần đến chúng tôi – chúng tôi đã sẵn sàng, và đã thực hiện một phiên bản beta khác của bảng kê cho 2% người dùng. Phản hồi rất tố và các bảng kê được nhập vào mà không có vấn đề gì xảy ra.

Ra mắt ứng dụng

Tại sao quyết định này lại là một sai lầm?

Bạn có thể nhận ra không? Nếu có, thì Shopify đang tuyển dụng đấy :))

Một vài phần khác của bối cảnh: Đối với hầu hết chủ sở hữu, giai đoạn báo cáo thuế sẽ đi chung với lịch năm ( Tháng 1 – 12), vì vậy nên thuế 2016 sẽ bao gồm bất cứ sự chuyển đổi nào diễn ra giữa tháng 1/2016 đến tháng 12/016.

Hạn cuối nộp thuế thường là vào tháng 6 năm sau, điều này có nghĩa là chủ sở hữu có thể có một vài lần bắt đầu chia sẻ bảng ke với kế toán vào tháng 1/2017

Chỉ mình sự thật này không ảnh hưởng lắm đến chúng tôi bởi vì thời gian chủ sở hữu xuất các bản kê không ảnh hưởng lắm vì dữ liệu trong các lần xuất sẽ tôn trọng bất kì phạm vi ngày nào mà chủ sở hữu đã chọn ( Vd: Lựa chọn tất cả các thay đổi trong năm 2016)

Nhưng chính hành vi cùng với giả thiết xấu chúng tôi đã thực hiện về chủ sở hữu dẫn tới sự thất bại của chúng tôi

Giả thiết xấu mà chúng tôi thực hiện chính là:

Chủ sở hữu ghi lại các giao dịch trong app khi chúng xảy ra trong suốt cả năm

Sự thật là hầu hết các chủ sở hữu, như mọi người, hay trì hoãn và không thực sự ghi lại các giao dịch trên app trừ khi họ phải làm vậy nghĩa là thời gian khi họ cần làm việc với kế toán để nộp thuế,.. nghĩa là vào năm sau.

Sự kết hợp của giả thiết xấu này + các hành vi xuất dữ liệu của chủ sở hữu + quyết định thực hiện lựa chọn 2 căn bản làm tính năng trở nên vô dụng với hầu hết chủ sở hữu.

Điều này có nghĩa là việc các chủ sở hữu trì hõan bắt đầu nhập các giao dịch 2016 vào đầu 2017, tât cả các giao dịch sẽ được coi là thực hiện vào 2017, và bảng kê 2016 hoàn toàn trống rỗng.

Điều này. Chắc chắn. 100%. Là thảm họa.

Hậu quả

Chỉ 25% người sử dụng FreshBooks thường xuyên ghi nhân giao dịch suốt năm mới có thể sử dụng tính năng bảng kê. Những người còn lại, đơn giản là tiếp tục làm việc với các kế toán một cách thủ công để làm các báo cáo của FreshBooks trở nên dễ hiểu

Đây là Kicker: Vì chúng tôi bắt đầu chạy sản phẩm vào tháng 1 nên mãi tới tháng 6 mới biết được đã có vấn đề xảy ra! Trong suốt thời gian đó, chúng tôi đã tiệc tùng, chúc mừng số lượng bảng kê được gửi tăng dần, và lãng phí nhiều phản hồi của chủ sở hữu về việc gửi các bảng kê “… rất dễ dàng, cám ơn nhé” (họ không nhận ra dữ liệu trở nên vô dụng bởi vì các dữ liệu được xuất ra một cách tượng hình cơ bản). Team của chúng tôi thậm chí còn chuyển sang dự án khác.

Ơn trời là, ngay khi chúng tôi bắt đầu nghe về feedback, một team khác đã nhận việc này và nhanh chóng sửa tính năng vào thời gian sau để sử dụng ngày mà chủ sử hữu nhập dữ liệu (lựa chọn 1). Không may là chủ sở hữu vẫn gặp các vấn đề khi nhân đôi chi phí, nhưng nếu có 2 điều xấu, tốt nhất là hãy chọn điều ít xấu hơn. Kể từ khi thay đổi, bảng kê trong FreshBook đã thực sự trở nên hữu ích với chủ sở hữu.

Bài học kinh nghiệm

Chúng tôi không mất khách hàng vì tính năng tệ hại này, tuy nhiên quyết định của tôi đã khiến cả team tốn thời gian làm việc chăm chỉ nhiều tháng vô ích.

May mắn là tôi đã qua khỏi cơn thịnh nộ, và team tôi đã chuyển sang làm một sản phẩm khác có tác động cao nhất cho FreshBook vào năm sau. Là một PM, khi thực hiện quyết định tồi tệ như vậy đã dạy tôi một bài học nhớ đời mà tôi đã nằm lòng hôm nay:

1. Phải nhận ra tác động của quyết đinh mình đã thực hiện, cho dù nó chỉ là một quyết định nhỏ đi chăng nữa. Một khi PM quyết định sẽ ảnh hưởng đến cả team và quy mô của sản phẩm. Hãy cảnh giác và luôn phải đi sâu vào chi tiết.
2. Suy nghĩ thật kĩ càng về các quyết định được thực hiện dựa trên giả thiết. Giả thiết chỉ ra khó khăn nhất và những thứ đã ăn sâu vào trong công ty mà hầu hết mọi người đều quên rằng chúng là giả thiết. Thứ 2 là những giả thiết đã ẩn sâu vào thành kiến cá nhân khiến chúng ta không có nhận thức về nó
3. Các nghiên cứu và xác nhận từ khách hàng đều rất quan trọng, tuy nhiên không phải lúc nào cũng là cơ sở để bạn quyết định. Trong câu chuyện này, tất cả các dấu hiệu đều tích cực nhưng chúng tôi cuối cùng vẫn thực hiện sai sản phẩm. Khách hàng không thể nói cho bạn biết nên xây dựng như thế nào vì họ chỉ có thể thấy phần sản phẩm mà họ tương tác cùng chứ không phải toàn bộ hệ thống đang được xây dưng.

Tôi hi vọng câu chuyện này sẽ xoa dịu hội chứng mạo danh mà hầu hết PM đều phải đối mặt hàng ngày khi cả team đều nhìn vào chúng ta mà đưa ra quyết định. Đây là một công việc cần đưa ra quyết định nhanh chóng tuy nhiên có nguy cơ cao với trách nhiệm vô hạn cho những quyết định đó.

Điều tồi tệ sẽ xảy ra. Bạn có thể không phải là người hoàn hảo nhưng không có nghĩa bạn sẽ không thể trở thành 1 PM tốt.

Nguồn: blackboxofpm.com