Đọc Inspired của Marty Cagan để FDE thôi làm "feature factory" cho khách hàng

Thử hình dung tuần đầu bạn ngồi ở văn phòng khách hàng, và họ đưa bạn một file có 14 dòng, mỗi dòng là một tính năng. Bạn làm xong cả 14 dòng, đúng hạn. Ba tháng sau, chẳng ai nhớ dashboard thứ 9 dùng để làm gì, và hợp đồng gia hạn vẫn chưa ký.

Kiểu thất bại này có tên. John Cutler, người làm ở Amplitude và là người phổ biến thuật ngữ “feature factory”, cho rằng vấn đề không nằm ở chuyện giao nhiều tính năng. Theo ông, đội bắt đầu lệch hướng khi không còn ai bỏ công tìm hiểu xem những gì đã giao tác động ra sao trong trung hạn và dài hạn.

FDE dễ rơi vào bẫy này hơn kỹ sư product thông thường, vì khách hàng nằm ngay trước mặt và luôn có sẵn một danh sách. Đó là lý do một tác giả viết cho product manager lại đáng nằm trên bàn của bạn.

Cuốn sách nói về điều gì, và phần nào không dành cho bạn?

Tên đầy đủ là INSPIRED: How to Create Tech Products Customers Love, bản thứ hai, của Marty Cagan. Wiley phát hành bản e-book vào tháng 11/2017 và bản bìa cứng vào tháng 12/2017. Cagan điều hành SVPG, và trang sách trên website của công ty mô tả cuốn này như một lớp học bài bản về cách tổ chức và tuyển người cho một đội sản phẩm.

Chi tiết đó cho bạn biết nên đọc thế nào. Chuyện cơ cấu tổ chức và tuyển người cho đội sản phẩm là những thứ một FDE hiếm khi được quyết định, nên bạn có thể đọc lướt. Thứ đáng giữ lại là cách Cagan nghĩ về vấn đề và kết quả, và ông trình bày những ý này gọn nhất trên blog SVPG.

Vì thế, một gợi ý về thứ tự: đọc hai bài ngắn “Product vs Feature Teams” và “The Four Big Risks” trước, rồi mới mở sách.

Output không phải là kết quả

Ý đáng mang theo nhất trong cách nghĩ của Cagan là ranh giới giữa output và outcome. Trong bài “Product vs Feature Teams”, ông định nghĩa mục đích của một đội sản phẩm là giải quyết vấn đề theo cách mà khách hàng yêu thích, đồng thời phải mang lại hiệu quả cho doanh nghiệp.

Ông viết rằng đội sản phẩm được định hướng và đánh giá bằng outcome, còn feature team thì xoay quanh output.

Áp vào chỗ khách, ví dụ dễ thấy nhất là một yêu cầu kiểu “thêm nút export ra Excel cho màn hình đơn hàng”. Đó là output. Nếu hỏi tiếp, có thể bạn sẽ biết rằng nhân viên điều phối đang mất nhiều giờ mỗi ngày để đối chiếu đơn hàng bằng tay.

Lúc này outcome là giảm thời gian đối chiếu, và nút export chỉ là một trong nhiều cách để đạt được nó, chưa chắc đã là cách tốt nhất.

Ở chỗ khách, việc bạn nên làm đầu tiên là gắn mỗi tính năng với một con số. Nếu cả bạn lẫn khách đều không nói ra được tính năng sẽ làm thay đổi con số nào, thì đó là dấu hiệu bạn đang chạy dây chuyền.

Roadmap dạng danh sách biến đội kỹ thuật thành người làm theo lệnh

Ranh giới ấy kéo theo một cách nhìn khác về roadmap. Trong bài “The Alternative to Roadmaps”, Cagan mượn lời cảnh báo của một vị tướng và viết rằng roadmap điển hình làm đúng điều vị tướng ấy khuyên tránh: bảo đội phải làm gì.

Trong bài về feature team, ông nhận xét rằng các đội nhận danh sách việc đã sắp sẵn ưu tiên như vậy thường hoàn toàn không được trao quyền.

FDE rất dễ vô tình tái tạo đúng cấu trúc này cho khách. Bạn nhận backlog, chia task, báo cáo tiến độ theo số dòng đã xong, và khách đánh giá bạn bằng chính con số đó. Cagan đề xuất một hướng khác cho roadmap, và câu ông dùng rất gọn: mọi thứ là chuyện outcome chứ không phải output.

Bạn có thể áp dụng ngay trong buổi lập kế hoạch tiếp theo. Thay vì gửi khách bản kế hoạch 14 tính năng, hãy gửi ba vấn đề cần giải quyết, mỗi vấn đề kèm chỉ số đo và vài hướng giải pháp có thể thử. Bạn vẫn giao code, nhưng cuộc trao đổi đã chuyển sang chuyện kết quả.

Bốn rủi ro: bộ lọc trước khi viết dòng code đầu tiên

Công cụ thực dụng nhất với người làm kỹ thuật là khung bốn rủi ro mà Cagan mô tả trong bài “The Four Big Risks”, và có ba loại FDE gặp hằng ngày. Rủi ro value là liệu khách có mua hoặc người dùng có chọn dùng nó hay không.

Rủi ro viability là liệu giải pháp có ổn với phía doanh nghiệp, xét trên đủ mọi mặt, hay không. Rủi ro feasibility là liệu kỹ sư có làm được trong khuôn khổ thời gian, kỹ năng và công nghệ hiện có hay không.

Quay lại nút export. Về value, nhân viên điều phối có thật sự mở file Excel hay họ cần một màn hình đối chiếu ngay trong hệ thống? Về viability, chính sách dữ liệu của khách có cho phép đưa thông tin đơn hàng ra file rời không? Về feasibility, với stack hiện tại và hai tuần còn lại, bạn làm được phiên bản nào?

Trong cùng bài viết, Cagan giao value và viability cho PM, còn feasibility cho kỹ sư. Ở chỗ khách, FDE thường phải gánh cả ba vai, nên hãy biến ba câu hỏi này thành một checklist bắt buộc trước khi nhận bất kỳ yêu cầu nào lớn hơn vài ngày công.

Thử luyện với một yêu cầu thứ hai: khách muốn hệ thống gửi email cảnh báo mỗi khi một đơn hàng trễ hạn. Trước khi nhận việc, hãy viết ra một câu trả lời cho từng rủi ro.

Về value, người nhận có đọc email không, hay sẽ lọc nó đi khi mỗi ngày có hàng chục đơn trễ? Về viability, ai bên khách chịu trách nhiệm xử lý cảnh báo, và quy trình của họ có chỗ cho bước đó không? Về feasibility, dữ liệu thời điểm giao hàng trong hệ thống có đủ tin cậy để xác định đơn trễ không?

Câu nào bạn chỉ trả lời được là “chưa biết”, đó chính là việc discovery cần làm trước khi viết dòng code đầu tiên.

Biến cách nghĩ này thành lợi thế khi đi xin việc

Tự nhận mình có tư duy sản phẩm thì dễ, chứng minh mới khó, và ngôn ngữ outcome của Cagan cho bạn cách làm điều đó. Trên CV, thay vì ghi “xây 12 tính năng cho khách hàng logistics”, hãy viết vấn đề bạn đã giải quyết và con số đã thay đổi.

Khi đọc mô tả công việc, hãy để ý những cụm như “customer discovery”, “own outcomes” hay “work with customers to define the problem”. Đó là những đội kỳ vọng bạn đặt câu hỏi chứ không chỉ nhận ticket. Ở vòng phỏng vấn, hãy chuẩn bị sẵn một câu chuyện về lần bạn từ chối hoặc đổi hướng một yêu cầu của khách sau khi kiểm ba rủi ro trên.

Inspired được viết cho người xây dựng đội sản phẩm, không phải cho FDE. Nhưng câu hỏi xuyên suốt cách nghĩ của Cagan, rằng bạn đang giao tính năng hay đang giải quyết vấn đề, chính là điều phân biệt một FDE được khách giữ lại với một nhà thầu được khách thay thế.