Josh Elman: Bản chất quản trị sản phẩm là kể chuyện, AI chỉ thay đổi cách chúng ta xây dựng

Mỹ | Công nghệ | Ý kiến | Văn hóa | Biểu đồ

Quản lý sản phẩm (product management) thực chất là kể những câu chuyện. Vì vậy, hãy để tôi chia sẻ cách tôi tư duy về quản lý sản phẩm và cách AI đã thay đổi lĩnh vực này thông qua một câu chuyện.

Tôi bắt đầu sự nghiệp với tư cách là kỹ sư tại RealNetworks, và chỉ vài năm sau, tôi đã chịu trách nhiệm về đội ngũ sản phẩm và kỹ thuật cho RealPlayer. Đó là một sản phẩm tiêu dùng khá quan trọng vào thời điểm đó - nó có hàng trăm triệu người dùng và góp phần đưa âm thanh, video đến với internet thời kỳ đầu. Tôi thường ngồi trong các cuộc họp với những người bên phía kinh doanh, những người luôn gợi ý các ý tưởng như: "Chúng ta nên hiển thị quảng cáo mỗi khi trình phát khởi động". Tôi biết đó không phải là điều đúng đắn, nhưng tôi không có cách nào để phản bác lại các bảng tính Excel của họ, thứ cho thấy chúng tôi sẽ kiếm được bao nhiêu tiền. Tôi muốn trở thành một quản lý sản phẩm thực thụ và đi đến kết luận rằng mình nên đi học trường kinh doanh.

Tôi bắt đầu học trường kinh doanh tại Berkeley, và ngay sau khi đến đó, tôi thấy trên danh sách email của trường cũ rằng LinkedIn đang tuyển dụng. Tôi ứng tuyển và thấy mình đang trong buổi phỏng vấn với Reid Hoffman. Ông ấy ngồi xuống và hỏi tôi một câu hỏi phỏng vấn mà tôi sẽ không bao giờ quên:

"Vậy, bạn muốn trở thành một quản lý sản phẩm. Sản phẩm (artifact) mà một quản lý sản phẩm tạo ra là gì?"

Ông ấy giải thích thêm. Các kỹ sư có sản phẩm là: mã nguồn (code). Phát triển kinh doanh có sản phẩm là: các hợp đồng đã ký kết. Các nhà thiết kế tạo ra giao diện hình ảnh và đồ họa. CEO có sơ đồ tổ chức, kế hoạch tài chính và tầm nhìn gắn kết mọi người lại với nhau. Còn quản lý sản phẩm thì sao?

Tôi nói với ông ấy rằng tôi không chắc các quản lý sản phẩm thực sự có những "sản phẩm" như vậy, nhưng điều cơ bản chúng tôi làm là tập hợp mọi thứ đang diễn ra và viết chúng vào một bản đặc tả (spec). Bản đặc tả chính là bản thiết kế. Đó là nơi chúng tôi xác định các yêu cầu và mọi thứ chúng tôi sẽ thực hiện, và nó trở thành một trong những tài liệu quan trọng nhất trong công ty vì nó giúp mọi đội ngũ bắt đầu xây dựng từ đó.

Rõ ràng là tôi đã rất lo lắng. Tôi nghĩ ông ấy nhận ra điều đó, vì ông ấy trấn an tôi rằng đó là một câu trả lời ổn. Cuối cùng tôi đã nhận được công việc, bỏ học trường kinh doanh để gia nhập LinkedIn, và kể từ đó tôi vẫn luôn suy nghĩ về câu hỏi đó.

Bởi vì tôi đã đưa ra câu trả lời sai.

Đó vẫn là Kỷ nguyên Waterfall (Thác nước) trong xây dựng phần mềm. Tại LinkedIn, chúng tôi đang cố gắng tái hình dung một nền tảng việc làm trong một nền tảng xã hội - nơi các nhà tuyển dụng có thể thấy các đơn ứng tuyển trong bối cảnh các kết nối chung, ứng viên có thể thấy các tin tuyển dụng và tìm cách thông qua mạng lưới của họ để tiếp cận cơ hội. Trong quá trình khám phá này, tôi đã viết một bản đặc tả dài 120 trang xác định toàn bộ trải nghiệm và các yêu cầu cần thiết.

Tôi đã suy nghĩ rất nhiều về điều đó trong những năm qua. Bởi vì bản đặc tả đó, rõ ràng, không phải là sản phẩm quan trọng nhất. Câu chuyện mới là thứ quan trọng nhất.

Bản đặc tả mô tả một hệ thống, những gì nó phải làm và những ô nào cần được đánh dấu trước khi hoàn thành. Đó không phải là nghệ thuật quản lý sản phẩm. Quản lý sản phẩm là kể câu chuyện về những người sẽ sử dụng sản phẩm đó và tại sao nó lại quan trọng trong cuộc sống của họ. Nó phải dễ hiểu ngay lập tức đối với bất kỳ ai mà bạn đang trò chuyện. Và nó phải có tính lan tỏa - mọi người cần có thể truyền đạt lại nó một cách trung thực mà không cần bạn phải có mặt ở đó.

Đó là một tài liệu hoàn toàn khác và một công việc hoàn toàn khác.

Mười năm trước, tôi đã có một bài nói chuyện về quản lý sản phẩm và mọi người vẫn gửi nó cho tôi; điều đó vừa đáng tự hào, vừa là dấu hiệu cho thấy lĩnh vực này chưa có nhiều thay đổi. Tôi sẽ cân nhắc cả hai khả năng. Dù sao thì, toàn bộ bài nói chuyện đó chỉ gói gọn trong một câu: "Một quản lý sản phẩm giúp đội ngũ (và công ty) của họ đưa sản phẩm phù hợp đến tay người dùng". Tôi đã dành phần lớn thời gian của bài nói chuyện để phân tích câu đó, từng từ một.

Giúp đội ngũ của họ. Bạn không phải là người lãnh đạo. Rất nhiều người nghĩ rằng quản lý sản phẩm là người lãnh đạo. Bạn là người giúp mọi thứ diễn ra. Điều đó có nghĩa là bạn phải…

Hiểu đội ngũ và công ty của bạn. Đội ngũ là lĩnh vực của bạn: bạn phải hiểu nó! Và bạn phải hiểu cách nó nằm trong bức tranh lớn hơn, để bạn có thể phục vụ các mục tiêu của công ty chứ không chỉ mục tiêu của riêng bạn.

Đưa sản phẩm ra thị trường (Ship). Chúng ta có thể nói bao nhiêu tùy thích, nhưng cuối cùng, điều quan trọng nhất là đưa sản phẩm đến trước mặt khách hàng.

Sản phẩm phù hợp cho người dùng của bạn. Cuối cùng chúng ta cũng đến được với công việc chính: tập trung vào việc "phù hợp" thực sự có nghĩa là gì.

Bao nhiêu phần trong đó thay đổi trong thế giới AI?

Rõ ràng là có thứ gì đó đã thay đổi, thực tế là một vài thứ. Một mặt, nó đang thay đổi cách chúng ta viết code và tốc độ chúng ta đi từ ý tưởng đến một thứ gì đó có thể vận hành. Mặt khác, nó đang thay đổi kỳ vọng của người dùng về một sản phẩm. Tôi nghĩ chúng ta mới chỉ khai thác bề nổi của điều này, đặc biệt là trong mảng tiêu dùng. Khả năng mô tả những gì bạn cần và để sản phẩm thực hiện nó, có thể với các tác nhân (agents) chạy ngầm, mà bạn không cần phải học cách sử dụng hay giao tiếp phức tạp.

Không còn nghi ngờ gì nữa, chi phí để tạo ra mọi thứ đã sụp đổ. Việc xác định phạm vi và thử nghiệm một thứ gì đó không còn quá khó khăn; điều đó mang lại cho bạn sự linh hoạt to lớn. Nhưng chi phí cho sự phán đoán thì không hề thay đổi. Việc tìm ra cái gì cần xây dựng giờ đây quan trọng hơn bao giờ hết.

Phát triển sản phẩm là một vòng lặp. Trước đây, ai đó có một ý tưởng - và không nhất thiết phải là bạn; trong một công ty tốt, nó có thể đến từ bất cứ đâu. Bạn thử nghiệm nó. Bạn viết một bản đặc tả, hoặc bản tóm tắt sản phẩm, hoặc bất cứ tên gọi nào bạn đặt cho tài liệu đó. Có một số chi phí ban đầu cho việc này: xác định phạm vi, thiết kế, tranh luận - mọi thứ phải xảy ra trước khi bạn tiêu tốn thời gian quý báu của đội ngũ kỹ thuật. Đây đều là những nghi thức mà chúng ta đã phát minh ra để bảo vệ thời gian của kỹ thuật khỏi những quyết định tồi tệ. Bởi vì bạn chỉ có sáu hoặc tám vòng lặp như vậy mỗi năm.

Sau đó, việc tạo ra mọi thứ trở nên rẻ đến mức phi lý. Không phải rẻ hơn một chút; mà là một bậc độ lớn khác biệt. Và những gì đã xảy ra thực sự rất thú vị. Vòng lặp cũ đó vẫn còn đó - chỉ là được sắp xếp lại theo một trật tự mới.

Vòng lặp cũ là: ý tưởng, đặc tả, tính toán chi phí, xác định phạm vi, mọi thứ khác, rồi mới xây dựng. Bây giờ:

Đầu tiên, lấy ý tưởng và xây dựng nó nhanh chóng với AI, chỉ để xem nó hoạt động như thế nào và cảm giác ra sao.

Bạn được chơi với nó, và tìm ra cảm giác của nó cũng như cách nó phù hợp với bức tranh tổng thể. Các bản mẫu (prototypes) luôn đánh bại các câu hỏi "nếu như".

Sau đó, bạn thiết kế nó. Bây giờ khi đã trải nghiệm nó, bạn biết nó là gì và bạn có thể thực sự thảo luận về những gì cần thiết để biến nó thành một sản phẩm thực thụ chứ không chỉ là bản mẫu. Tôi muốn nói đến thiết kế theo cả hai nghĩa: thiết kế hình ảnh và UX, cũng như thiết kế kỹ thuật.

Sau đó, bạn đưa sản phẩm ra thị trường và học hỏi.

Nó hoàn toàn đảo ngược: từ đặc tả-và-phạm vi, sang xây dựng-và-trải nghiệm. Tôi nghĩ điều đó thay đổi quản lý sản phẩm nhiều hơn bất cứ thứ gì khác đang diễn ra hiện nay.

Điều này cuối cùng có nghĩa là bản đặc tả không còn là sản phẩm bàn giao; thực sự là như vậy. Bạn không cần phải bắt đầu bằng việc viết một tài liệu dài và đảm bảo mọi thứ đều đúng trên giấy. Điều này từng đúng theo nghĩa kỳ vọng, nhưng giờ đây nó hiển nhiên đúng theo nghĩa đen.

Nhưng tôi muốn cẩn trọng, bởi vì có một sai lầm tương tự và trái ngược mà bạn có thể mắc phải.

Các bản demo giờ đây gần như miễn phí. Các sản phẩm hoạt động được thì không. Tôi liên tục thấy mặt trái của cách tiếp cận mới này: "Thật tuyệt, cứ tung ra đi". Đó vẫn không phải là cách nó vận hành. Tất cả chúng ta vẫn phải tôn trọng rằng khoảng cách từ một bản mẫu đến một thứ gì đó thực tế vẫn cần thời gian để vượt qua.

Có một quan niệm khá phổ biến về các quản lý sản phẩm, rằng công việc của họ chủ yếu là hỏi: "Nó có phù hợp với lịch trình không?". Hãy vứt bỏ hoàn toàn ý tưởng đó đi. Câu hỏi quan trọng nhất là: Nó có phù hợp với sản phẩm không?

Tất cả chúng ta đều có những ý tưởng tuyệt vời, và giờ đây tất cả chúng ta đều có các tác nhân (agents) có thể viết code thay cho mình. Quyết định cái gì cần xây dựng chính thức không còn là cuộc tranh luận về nguồn lực. Đó là cuộc tranh luận về tác động. "Cái này hay cái kia", chứ không phải "cái này hay không có gì cả". Gu thẩm mỹ và sự chọn lọc rất quan trọng ở đây, khi bạn có một tầm nhìn và thực sự biết mình đang cố gắng làm gì cho thế giới. Nhưng hệ thống bạn xây dựng vẫn phải mang lại cảm giác hoàn chỉnh.

Nỗi lo lớn nhất của tôi về AI là nó cho phép chúng ta đi nhanh hơn, và do đó chỉ nhồi nhét mọi thứ vào. Chúng ta nói về "AI slop" (rác AI) trong nội dung; đây là ý nghĩa của AI slop đối với sản phẩm. Tôi đã thấy nó xảy ra ở một vài nơi và tôi nghĩ tất cả chúng ta đều hơi lo lắng về điều đó. Khi bất kỳ ai cũng có thể xây dựng bất cứ thứ gì, việc quyết định xây dựng cái gì mới là toàn bộ công việc. Và đó là một vấn đề về kể chuyện. Bạn muốn kể câu chuyện nào? Bạn muốn khách hàng của mình hiểu câu chuyện nào? Bạn muốn câu chuyện nào tồn tại trong tâm trí họ?