50 bài học rút ra khi xây dựng một sản phẩm thành công [Bài dịch]

1. Các nhóm nhỏ (6 người trở xuống) có thể tạo ra sản phẩm tuyệt vời, nhưng họ phải được trao toàn quyền tự chủ trong việc đặt mục tiêu, ưu tiên roadmap, chọn metric, giao tiếp với người dùng và triển khai mã nhanh chóng.

2. Thành công của sản phẩm phụ thuộc vào những người tạo ra nó. Điều cốt lõi là phải đặt tiêu chuẩn tuyển dụng cao, vì năng lực của nhân tài có tính cộng dồn. Một tuyển dụng sai có thể làm chậm tốc độ của cả đội hơn bất kỳ yếu tố nào khác.

3. Niềm tin là yếu tố thiết yếu để tạo ra sản phẩm tuyệt vời. Thiếu niềm tin là một trong những điểm nghẽn lớn nhất của đội ngũ, và điều này thường là hệ quả của việc tuyển người chưa đủ năng lực hoặc không đưa ra phản hồi cải thiện đúng cách cho họ.

4. Niềm tin cũng được xây dựng bằng sự minh bạch. Hãy làm việc công khai, thảo luận ở không gian mở và ghi lại tài liệu về công việc. Làm vậy giúp mọi người cùng chia sẻ ngữ cảnh cần thiết và loại bỏ những đấu đá chính trị thường thấy ở nhiều công ty.

5. Hãy dựa vào niềm tin và phản hồi, thay vì quy trình. Đây là một trong những giá trị cốt lõi của chúng tôi. Xây dựng và phát triển thứ mà con người thực sự muốn là một vấn đề tinh tế, nên chúng tôi tin vào phán đoán của nhân viên. Nếu có gì sai, hãy phản hồi thẳng thắn.​

6. Ban lãnh đạo chia sẻ mục tiêu công ty, còn đội sản phẩm (kỹ sư) quyết định sẽ xây gì để đạt được mục tiêu đó và đặt ra mục tiêu riêng. Cả hai bên đều phải xem xét tác động thực tế bằng metric và phản hồi người dùng.

7. Sản phẩm phụ thuộc vào hồ sơ khách hàng lý tưởng (ideal customer profile, ICP). ICP chính là đối tượng bạn xây dựng cho, và là yếu tố quan trọng nhất quyết định nên xây gì. Một ICP chính xác không chỉ xác định khách hàng mục tiêu mà còn định hình mọi khía cạnh của sản phẩm và chiến lược go-to-market.

8. Để tìm ra ICP, trước hết hãy đưa ra giả định rồi kiểm chứng. Đặt câu hỏi khi người dùng đăng ký, so sánh retention, xác định power user và thực hiện khảo sát NPS. Khi thông tin và độ chắc chắn tăng lên, hãy bổ sung thêm chi tiết.

9. Hãy xây dựng các nguyên tắc sản phẩm. Chúng tôi lấy các nguyên tắc như “cung cấp mọi công cụ cần thiết để đánh giá thành công, chiếm lĩnh trước, đóng vai trò là nguồn chân lý duy nhất cho dữ liệu khách hàng và dữ liệu sản phẩm”. Điều này tạo ra một ngôn ngữ chung cho việc thảo luận ý tưởng và ra quyết định.

10. Hãy lập bản đồ mọi thứ người dùng có thể muốn. Điều này cần thiết khi ưu tiên roadmap. Làm vậy sẽ giúp bạn không bỏ lỡ những ý tưởng tuyệt vời nằm ngoài tầm nhìn trước mắt.

11. Sản phẩm không chỉ là tập hợp tính năng. Nó còn là thương hiệu và trải nghiệm sản phẩm mà bạn mang lại cho người khác. Mức độ đầu tư vào từng tính năng, những người bạn tuyển, các quyết định xây dựng, tính năng dẫn dắt, cách giao tiếp với khách hàng và chính sách giá đều tạo nên sự độc đáo.

12. Website là ấn tượng đầu tiên của sản phẩm. Một website nhàm chán, rập khuôn sẽ phát đi tín hiệu rằng sản phẩm và đội ngũ phía sau cũng yếu kém. Tự tạo một website độc đáo phù hợp với ICP sẽ ngăn điều đó và thúc đẩy thu hút người dùng.

13. Đôi khi vấn đề không nằm ở sản phẩm mà ở thị trường. Ví dụ, khi Tom Blomfield, nhà sáng lập Monzo và đối tác YC, xây dựng một dịch vụ chia hóa đơn cho bạn đại học, ông được khuyên hãy ngừng build và tập trung thu hút người dùng. Sau 4 tuần cold calling mà chỉ có được một người dùng, ông biết đã đến lúc pivot.

14. Nếu pivot, hãy làm thật quyết liệt. Stewart Butterfield đã biến hai công ty game thành Flickr và Slack. Đồng sáng lập LinkedIn Reid Hoffman nói rằng để pivot từ thất bại sang thành công, các nhà sáng lập startup phải “slash and burn” phần còn lại của doanh nghiệp. Nếu nó trông vẫn còn giống cũ, hãy đi xa hơn nữa.

15. Như Jason Fried của 37signals nói: “Bạn không thể xác thực một ý tưởng. Nó chưa tồn tại, nên bạn phải thực sự xây nó. Thị trường sẽ xác thực nó.”

16. Kế hoạch thì hữu ích, nhưng không phải để tuân theo một cách cứng nhắc. Thực thi tốt không phải là hoàn thành một kế hoạch cụ thể, mà là lặp đi lặp lại việc quan trọng nhất. Đừng đánh giá con người bằng việc họ có “theo đúng kế hoạch” hay không, mà bằng những gì họ ship, tần suất ship và tác động tạo ra.

17. Trì hoãn điều gì đó thêm “chỉ một tuần nữa thôi” gần như luôn là một ý tưởng tệ. Khi thái độ này tích lũy qua vài tháng, động lực sẽ giảm mạnh. Càng đưa sản phẩm vào tay người dùng sớm, bạn càng sớm hiểu được giá trị của nó và cải thiện nó.

18. Hãy giảm lượng công việc đang làm dở. PR nên được hoàn thành trong một ngày, bắt đầu ngày làm việc bằng việc phản hồi các yêu cầu review từ người khác, merge bất cứ lúc nào có thể, triển khai sau feature flag và test trong production. Tất cả điều này làm giảm gánh nặng ngữ cảnh của công việc.

19. Triển khai nhanh là cốt lõi trong triết lý phát triển sản phẩm của chúng tôi, nhưng có đánh đổi. Mua sắm công nghệ, họp lập kế hoạch, các nghi thức agile và review metric sẽ bị đẩy xuống ưu tiên thấp hơn. Làm việc bất đồng bộ giúp điều này khả thi hơn.

20. Chỉ đưa công nghệ mới vào sản phẩm khi gặp những vấn đề cấp bách như chi phí quá cao, vấn đề scaling hoặc yêu cầu từ khách hàng. Cách giải quyết thường có thể tìm ra bằng cách hỏi đội mình hoặc đội khác xem họ đã trực tiếp xử lý kiểu vấn đề đó như thế nào.

21. Deadline nhân tạo không làm đội ngũ nhanh hơn. Ngược lại, nó tạo ra một vòng lặp thảm họa với núi technical debt và burnout. Hãy loại bỏ các quy trình làm chậm đội ngũ và trao quyền tự chủ triển khai nhanh cho các nhóm nhỏ.

22. Một cách khác để triển khai nhanh hơn là bỏ qua bước thiết kế mặc định. Sau khi thiết lập design system, hãy để kỹ sư tự build. Khi cần, dùng review thiết kế để tinh chỉnh thứ đã được triển khai rồi.

23. Feature flag cho phép product engineer triển khai thay đổi nhanh, test trong production và nhận phản hồi thực tế từ người dùng. Nó cũng giảm rủi ro bằng cách đóng vai trò như kill switch khi mọi thứ không hoạt động như mong đợi.

24. Ở PostHog, hình thức giao tiếp tốt nhất là pull request. Không giống tin nhắn hay issue, nó biến phản hồi thành tác động ngay lập tức. Nó phù hợp với thiên hướng ưu tiên hành động của chúng tôi và tạo ra vòng phản hồi chặt hơn.

25. Hãy làm rõ quyền sở hữu. Điều này giúp việc quyết định nên build gì trở nên rõ ràng và nhanh chóng hơn nhiều. Những đội né tránh ownership sẽ lãng phí thời gian vào lập kế hoạch, brainstorming, họp và quản lý dự án thay vì ship.

26. Kỹ sư có khả năng quyết định nên build gì. Họ hiểu các ràng buộc kỹ thuật, nhận ra các mẫu tính năng và biết cách giải quyết vấn đề. Tuy nhiên, có thể tồn tại điểm nghẽn thông tin về nhu cầu người dùng.

27. Thay vì kiểm soát kỹ sư, product manager nên cung cấp ngữ cảnh cho đội sản phẩm thông qua product analytics, nghiên cứu người dùng, nghiên cứu đối thủ cạnh tranh, v.v.

28. Phần lớn chúng ta không phải Steve Jobs. Chúng ta không có sẵn tầm nhìn để “tự biết” phải build gì ngay từ đầu, cũng không vẽ ra được bức tranh lớn hoàn chỉnh. Thay vào đó, hãy ship, đưa cho người dùng, rồi lặp lại vòng phản hồi. Tốc độ này càng nhanh, sản phẩm càng tốt hơn.

29. Hãy tuyển và tin cậy vào product engineer. Họ có cả kỹ năng full-stack lẫn sự ám ảnh với khách hàng cần thiết để xây sản phẩm. Họ nên tham gia trò chuyện với người dùng, phỏng vấn, tuyển người thử tính năng mới, thu thập phản hồi, xử lý hỗ trợ và ứng phó sự cố.

30. Hãy đọc The Mom Test. Cuốn sách này dạy cách trò chuyện về vấn đề của người dùng tiềm năng. Cốt lõi là hai kiểu phỏng vấn người dùng: khám phá vấn đề và xác thực giải pháp. Loại đầu giúp định hướng quyết định sản phẩm trong tương lai, loại sau giúp cải thiện công việc hiện tại.

31. Để đạt hiệu quả tối đa từ phỏng vấn người dùng, hãy xác định trước người dùng là ai (ICP), họ sử dụng sản phẩm như thế nào và bạn có thể build gì tiếp theo. Làm vậy giúp cuộc phỏng vấn làm rõ trọng tâm cho bước tiếp theo thay vì gây nhiễu.

32. Trong các khả năng có thể build, yêu cầu hỗ trợ là thứ “thực tế” nhất. Có một người dùng cụ thể đang gặp một vấn đề cụ thể, nên nếu bạn giải quyết nó, sản phẩm sẽ được cải thiện ngay lập tức. Những thay đổi khác không trực quan như vậy.

33. Khi kỹ sư xử lý hỗ trợ, điều đó khuyến khích ownership đối với toàn bộ vòng đời sản phẩm, từ lên ý tưởng đến triển khai rồi duy trì lâu dài. Mỗi giai đoạn đều kết nối với nhau thông qua pain point thực tế của khách hàng và ngữ cảnh mã nguồn đằng sau các issue đó.

34. Việc để kỹ sư xử lý hỗ trợ rút ngắn vòng lặp giữa vấn đề của người dùng và bản sửa lỗi được triển khai. Nhân viên hỗ trợ, product manager và quy trình lập kế hoạch sẽ không cản trở ở giữa. Thêm một lợi ích nữa là người dùng rất thích điều này.

35. Dogfooding giúp tăng tốc độ triển khai, chặn vấn đề trước khi chúng đến tay người dùng, hiểu sản phẩm sâu hơn và hình thành sự đồng cảm với người dùng. Tuy nhiên, nó không thay thế được việc trò chuyện với người dùng, phản hồi thực tế và theo dõi metric sử dụng.

36. Giống như đội sản phẩm của chúng tôi giải quyết nhu cầu nội bộ bằng popup phỏng vấn, việc giải quyết nhu cầu của chính mình là cách hiệu quả để xác thực use case. Nếu bạn lẽ ra phải dùng chính sản phẩm của mình mà lại không dùng, đó là dấu hiệu có gì đó không ổn và cần được sửa.

37. Những người xây sản phẩm vĩ đại luôn liên tục prototype và thử nghiệm. Họ phải quen với việc build MVP và proof of concept, triển khai công việc chưa hoàn chỉnh, thu thập phản hồi và pivot khi thất bại. Họ cũng cần mọi kỹ năng để build từ zero, từ hạ tầng đến thiết kế.

38. Một A/B test thành công cần có giả thuyết tốt giải thích rõ bạn đang test điều gì và vì sao. Hãy bao gồm ngữ cảnh của bài test, thay đổi được thực hiện, metric và kết quả kỳ vọng.

39. Khi làm thử nghiệm sản phẩm, hãy biết rằng nó có thể thất bại và bị loại bỏ. Hãy dùng feature flag để dễ xóa bỏ, và ship một phiên bản “đủ tốt” thay vì phiên bản hoàn hảo về bảo trì và scaling. Nếu thành công, bạn có thể cải thiện sau.

40. Thử nghiệm sản phẩm có thể được làm “ngốc nghếch” hơn nhiều so với bạn nghĩ. Thay vì build cả tính năng, hãy thử fake door test. Tức là thêm một lựa chọn hoặc nút mà chưa có gì phía sau, chỉ để xem người dùng có nhấp vào hay không.

41. Thất bại trong thử nghiệm sản phẩm không phải là tận thế. Ở Google, 80-90% thử nghiệm là “thất bại”. Điều này có thể trông như lãng phí thời gian, nhưng ở quy mô lớn, 10% thành công có thể bù cho mọi thất bại, như A/B test hiển thị headline của Bing đã tăng doanh thu 12% (hơn 100 triệu USD).

42. Khi tập trung vào tăng trưởng, hãy suy nghĩ và ưu tiên như một growth engineer. Xác định khu vực mục tiêu, chọn metric đại diện, đặt giả thuyết cải thiện rồi triển khai thử nghiệm nhỏ nhất có thể để kiểm chứng.

43. Việc triển khai analytics gần như không bao giờ là quá sớm. Điều đó đúng với sản phẩm trước khi ra mắt, nhưng việc nói “còn quá sớm” rồi ra mắt mà không có analytics là một kiểu tiết kiệm giả tạo. Sau khi ra mắt, ưu tiên sẽ chuyển từ ship nhanh nhất có thể sang ship thứ “đúng” nhanh nhất có thể.

44. Khi bắt đầu với analytics, hãy khởi đầu nhỏ. Chọn một sản phẩm hoặc tính năng cụ thể, theo dõi việc sử dụng bằng autocapture, trực quan hóa bằng biểu đồ xu hướng và retention, rồi thử ship những tính năng nhằm cải thiện chúng. “Tổ hợp công nghiệp modern data stack” khiến mọi thứ trông phức tạp hơn thực tế.

45. Nếu bạn không biết nên bắt đầu với metric nào, tôi khuyên là activation. Nó nằm ở tầng trên của nhiều metric khác, kỹ sư có thể tác động trực tiếp và nó hữu ích cho toàn tổ chức.

46. Ngoài activation, retention là một metric cốt lõi khác để hiểu tác động của việc build. Theo dõi thay đổi hàng tuần cho phép bạn ước lượng liệu các thay đổi có giúp giữ chân người dùng hay không.

47. Khi đo product-market fit, hãy xem liệu mức độ tương tác của người dùng có tăng theo cấp số nhân so với tăng trưởng người dùng hay không, và retention có đi ngang ổn định (lớn hơn 0%) hay không. Sau đó, hãy kiểm tra xem retention của nhóm người dùng ICP có nổi trội không và khách hàng trả tiền có thuộc ICP hay không.

48. Review tăng trưởng giúp xác nhận liệu những gì đội ngũ build có tác động đến các metric quan trọng như doanh thu, product analytics và phản hồi người dùng hay không. Ở PostHog, đây là trách nhiệm chính của product manager.

49. Khi build nhiều sản phẩm, hãy đối xử với từng sản phẩm như một startup thu nhỏ. Nó cần có các quyết định sản phẩm riêng, giá riêng, doanh thu, chi phí và sự phối hợp với các đội ngũ tiếp xúc khách hàng.

50. Hãy gắn bó với những sản phẩm khiến bạn thấy hứng thú. Như James, đồng sáng lập PostHog, đã viết trong hướng dẫn về product-market fit: “Nếu bạn không thấy hứng thú, hãy pivot. Chỉ vậy thôi. Bạn đạt thành tích lớn hơn khi bám vào thứ mang cảm giác đúng với chính mình.”