- Với ý tưởng sản phẩm, cần đặt ràng buộc trước để thu hẹp không gian khám phá và tránh trôi tới một kết quả quá phức tạp hoặc không có bản sắc
- Mọi ý tưởng đều պետք được tóm gọn trong một one pager; nếu không thể chứa trong đó, thì nên xem là vẫn cần thêm khảo sát, lập kế hoạch và nguyên mẫu
- Cần đồng thời xây dựng core tech có thể tồn tại độc lập với sản phẩm, để nó trở thành tài sản tích lũy vẫn tiếp tục được bồi đắp ngay cả khi đổi hướng
- Ở trung tâm sản phẩm cần có một defining constraint luôn hiện ra với người dùng; ràng buộc này sẽ tự nhiên quy định feel và bản sắc của sản phẩm
- Nếu chỉ một trong ba tiêu chí không vượt qua được, thì thái độ không làm mới là điều quan trọng để kiểm soát phạm vi và tạo đòn bẩy dài hạn
Ba ràng buộc đặt ra trước khi bắt tay làm
- Đặt ràng buộc trước khi làm sản phẩm sẽ thu hẹp không gian khám phá và ngăn việc trôi tới một kết quả phức tạp hoặc thiếu bản sắc
- Trong 10 năm làm nhiều sản phẩm, những sản phẩm quá phức tạp hoặc không có bản sắc đều dẫn tới thất bại, và sau nhiều lần thử sai, mọi thứ được cô đọng thành ba tiêu chí
-
Không làm nếu vượt quá một trang
- Mọi ý tưởng phải được tóm gọn trong một one pager, và tài liệu này đóng vai trò north star
- one pager phải không thể thỏa hiệp, chính xác, tham vọng nhưng không rườm rà
- Có thể dùng cùng một tài liệu này để giao tiếp với nhà đầu tư, người đóng góp, thành viên nhóm, bạn bè, gia đình và nhiều đối tượng khác
- Khi phát sinh xung đột trong hợp tác, những gì không có trong one pager thì không đáng để tranh cãi; nếu thực sự quan trọng thì phải sửa tài liệu để phản ánh vào đó
- Nếu chưa lấp đầy được một trang, thì không phải là cố nhồi thêm nội dung, mà nên xem là vẫn chưa sẵn sàng để làm
- Trong trường hợp đó, trước tiên cần khảo sát, lập kế hoạch, làm prototype rồi viết lại one pager
- Nếu dài đến mức vượt quá một trang thì nó quá phức tạp, nên không làm
-
Công nghệ cốt lõi phải tách rời khỏi sản phẩm
- Tách biệt với bản thân sản phẩm, cần tạo ra core tech đỡ phía dưới cho sản phẩm
- core tech có thể là phương pháp luận, công nghệ, công cụ hoặc một sản phẩm riêng, và phải sống được ngay cả khi không còn sản phẩm hiện tại
- Sự tách biệt này giúp không bị mắc kẹt trong một sản phẩm duy nhất và vẫn tiếp tục tích lũy ngay cả khi đổi hướng
- Sản phẩm thường xuyên đổi hướng, nhưng core tech vẫn còn lại như một tài sản liên tục và tích lũy
- Về dài hạn, những nỗ lực tích lũy như vậy có thể tạo ra lợi ích phi tuyến
- Ví dụ được đưa ra là git của Linus Torvalds, HCL của HashiCorp, Kubernetes của Google
- Không nhất thiết phải có nguồn lực cấp độ tập đoàn lớn; một thư viện tách ra từ codebase hoặc một phương pháp luận được liên tục mài giũa cũng có thể làm được
- core tech nên độc lập với hướng đi của sản phẩm, nhưng phải phù hợp với tầm nhìn dài hạn của cá nhân hoặc công ty
- Nếu một ý tưởng không mở ra khả năng cho core tech, thì đòn bẩy của nó chưa đủ lớn
-
Một ràng buộc quyết định phải định nghĩa sản phẩm
- Ở trung tâm sản phẩm phải có một defining constraint luôn hiện hữu với người dùng
- Ràng buộc này phải là yếu tố mà người dùng liên tục gặp và tương tác cùng, và nó tạo nên bản sắc của sản phẩm
- Một ràng buộc tốt sẽ tạo ra feel của sản phẩm và thấm vào toàn bộ trải nghiệm người dùng
- Minecraft được cấu thành chỉ bằng các khối, còn IKEA mang bản sắc đồ nội thất tự lắp ráp flat-pack; bản sắc được bộc lộ trực tiếp từ ràng buộc
- Những ràng buộc như vậy làm giảm không gian ra quyết định, giới hạn phạm vi và giúp tập trung vào vấn đề thực sự quan trọng
- Nếu không chọn ràng buộc hoặc chọn sai, sản phẩm sẽ trôi thành một thứ cồng kềnh muốn làm tất cả mọi thứ
- Khi có một ràng buộc được thiết kế tốt, thiết kế sản phẩm sẽ tự nhiên đi ra từ chính ràng buộc đó
- Ràng buộc này cũng phải được đặt ở vị trí nổi bật trên one pager
Tiêu chí kết luận
- Nếu chỉ một trong ba ràng buộc không vượt qua được, thì không làm
2 bình luận
Ý kiến trên Hacker News
Tôi vẫn gọi những thứ này là product primitives
Tức là những thứ như blocks của Notion, messages/conversations của Telegram, frames/layers của Figma, tweets của Twitter, cells/sheets của Excel, tools/layers của Photoshop, hay commands của CLI
Theo tôi, thiết kế sản phẩm tốt xuất hiện khi số lượng primitive kiểu này rất ít
Sản phẩm tệ là sản phẩm không biết primitive của mình là gì, hoặc có quá nhiều primitive đến mức mọi yếu tố bên trong sản phẩm cứ như hoạt động rời rạc riêng lẻ
Khi đó người dùng phải học cả đống khái niệm cấp cao khác nhau, nên dễ bối rối, e ngại và cũng khó hướng dẫn hơn
Lý tưởng nhất là chỉ cần một, hai hoặc ba primitive cốt lõi là đủ
Độ phức tạp và sức mạnh của một ứng dụng đến từ việc chọn được những primitive có chiều sâu và có thể kết hợp được
Phải là những đơn vị nhỏ nhưng làm được rất nhiều thứ, như block của Notion, cell của Excel, command của CLI hay block của Minecraft
Điều này trông khá giống với Alexandrian Pattern Language, nhưng thực ra có lẽ gần với Centers mà Alexander nói về sau hơn là pattern
Theo cách tôi hiểu, ngành phần mềm tiếp nhận pattern của ông khá mạnh, nhưng về cuối đời Alexander xem đơn vị cấu thành tối hậu của một hệ thống là Center
Đó là những thứ như sân trong sáng sủa, chỗ ngồi bên cửa sổ, lò sưởi — những điểm mang tính hữu ích cục bộ và là tâm điểm của sự kết tụ
Một center mạnh thì tự nhiên có thể kết hợp được, giải tỏa căng thẳng cục bộ, được cấu thành từ các center nhỏ hơn, và đóng vai trò như khối xây dựng tạo ra center lớn hơn
Sản phẩm trở nên hỗn loạn và phình to thường không phải vì ý đồ xấu
Nhu cầu người dùng thì bằng thực nghiệm thường vẫn tìm ra tương đối được, nhưng cấu trúc trung tâm thật sự có thể hấp thụ những nhu cầu đó một cách thanh nhã thì rất tinh tế nên khó phát hiện
Vì vậy, với mỗi nhu cầu trước mắt, con đường dễ nhất luôn là gắn thêm một giao diện cứng và riêng cho đúng nhu cầu đó
Muốn tìm được primitive cốt lõi có thể hấp thụ những nhu cầu như thế một cách tự nhiên thì cần làm việc kiến trúc rất sâu
Có lẽ vì thế mà rốt cuộc người ta cứ tiếp tục tạo ra faster horses
Trước đây tôi gọi chuyện này là concept count
Số lượng khái niệm cốt lõi cấu thành sản phẩm thường nên được giảm đến mức tối thiểu, và đôi khi cũng được gọi là nouns and verbs của sản phẩm
Triết lý này có vẻ bị đơn giản hóa quá mức
Tana thực tế gần như chỉ có hai primitive là bullets và supertags, nhưng lại phức tạp đến mức ngay cả tác vụ rất đơn giản cũng phải xem tutorial vài giờ mới dùng được
Ngược lại, Google Maps có khá nhiều primitive, nhưng với 90% trường hợp sử dụng thì UX vẫn được tổ chức rất chắc tay
Tôi cũng từng dùng tiêu chí tương tự khi nhìn vào ngôn ngữ lập trình
Có những ngôn ngữ quy mô lớn nhưng nhỏ về mặt khái niệm; học xong thì phần còn lại sẽ theo đến khi kinh nghiệm tích lũy dần, còn ngôn ngữ lớn về mặt khái niệm thì rào cản gia nhập rất cao
Ví dụ khiến tôi cảm nhận điều đó rõ nhất là perl
Nên nhỏ, nhưng không được nhỏ quá
Ví dụ điển hình là shell script (POSIX shell, bash), nơi người ta cố mô hình hóa cả scripting bằng command để khỏi phải đưa vào khái niệm mới; và kết quả, như ai cũng biết, là một hỗn hợp nóng, chậm và lộn xộn
Tôi thích cả ba ràng buộc, nhưng tôi nghĩ tài liệu 1 trang nên thay đổi theo độ phức tạp của dự án
Với các dự án quy mô nhỏ đến trung bình thì một trang là đủ, nhưng nếu là phần mềm điều khiển bay tới sao Hỏa thì trước khi bắt đầu triển khai có thể sẽ cần một one-pager có hyperlink tới vô số đặc tả con
Tách biệt công nghệ và sản phẩm là một ý rất khôn ngoan
Lấy Skype làm ví dụ, có công nghệ truyền thông P2P ở backend và ứng dụng gọi điện ở frontend, và các nhà sáng lập thông minh đã đặt hai phần này vào các công ty riêng biệt
Vì thế sau khi ứng dụng frontend là Skype được bán cho Microsoft, họ vẫn có thể tiếp tục nắm giữ riêng công ty sở hữu IP cốt lõi và công nghệ backend P2P
Lấy một ràng buộc làm trung tâm cũng hợp lý, nhưng đôi lúc tôi thấy có nhiều ràng buộc hoặc một danh sách ưu tiên sẽ tốt hơn
Nếu nguyên tắc tối thượng lại khó thương mại hóa, thì coi nó như giáo điều bất biến có thể đẩy công ty tới chỗ phá sản
Nếu trong đội có ý tưởng để pivot mạnh sang một hướng dễ bán hơn nhiều, thì dù khác khá xa ban đầu vẫn có thể mở ra đường sống
Twitter cũng là trường hợp ban đầu định làm thứ khác, rồi public status update lại xuất hiện từ một dự án phụ
Bài này tóm lược rất hay cách tôi từng cùng người hướng dẫn nghiên cứu xây dựng một doanh nghiệp
Chúng tôi bắt đầu từ hai điều cuối trước, tức là công nghệ cốt lõi và ràng buộc
Công nghệ cốt lõi là một sampler cho phép xây dựng mô hình đồ thị Bayesian phân cấp tùy ý cho sparse data, còn ràng buộc là mọi tính toán phải khả thi trong điều kiện bị giới hạn bởi CPU
Điều mất nhiều thời gian nhất là nhận ra rằng sản phẩm cuối cùng phải được tách khỏi công nghệ nền tảng
Ngay từ đầu tôi đã nghe nhiều người cho lời khuyên tương tự, nhưng có những bài học chỉ khi tự mình trải qua mới thật sự ngấm
Ý tưởng one-pager thực sự rất hay
Nếu bạn còn không dành ra được thời gian để viết rõ các ràng buộc chỉ trong một trang, thì cuối cùng bạn sẽ lao vào làm rồi hoảng hốt phát hiện ra những ràng buộc đó quá muộn
Và đó không phải là bug, mà là một khuyết tật ở mức chúng ta đã xây sai thứ ngay từ đầu
Tôi không thể chứng minh bằng dữ liệu, nhưng theo trải nghiệm của tôi, những dự án khiến mọi người cùng ở trên một mặt bằng khái niệm thường thành công thường xuyên hơn hẳn
Chỉ cần một tài liệu cấp cao dài một trang, nêu rõ chúng ta làm gì và không làm gì, cũng đã rất hiệu quả
Ngược lại, những dự án bị đẩy đi theo kiểu ứng biến thì đến cuối cùng ngay cả những người chưa từng nói rõ suy nghĩ của mình cũng đều thất vọng
Tôi ước tác giả cho một ví dụ hoàn chỉnh về việc ràng buộc thực sự vận hành như thế nào
Đặc biệt là mục thứ ba, tôi vẫn chưa hình dung rõ trong thực tế nó trông ra sao
Rốt cuộc có vẻ vẫn phải tự mình nghĩ ra cái gì đó
Tôi thấy những ý tưởng như everything's a file của Linux là rất hay
Chỉ một khái niệm mạnh như vậy thôi cũng có thể đi được rất xa
Ràng buộc đang bị đánh giá thấp
Những lời giải thanh nhã nhất thường không xuất hiện từ tự do vô hạn, mà từ việc tạo ra thứ gì đó dưới các ràng buộc rõ ràng
Và điều này cũng nối với ý thứ nhất
Chính quá trình viết one-pager giúp định nghĩa những ràng buộc đó
Việc Google có Kubernetes, trên hết có vẻ là để vô hiệu hóa đối thủ cạnh tranh
Nếu là solo SaaS thì ràng buộc tôi sẽ thêm vào là liệu trong tuần này có tìm được một người dùng beta hay không
Thời gian, phạm vi và công nghệ có thể nhìn rất ổn trên one-pager, nhưng nếu không ai bước vào thì dự án vẫn chết như thường
Thế nên tôi đưa ràng buộc về phân phối/phát hành vào ngay từ đầu, để xác thực nhóm có nhu cầu trước khi đào quá sâu vào tính năng
Tôi lo rằng câu công nghệ cốt lõi phải có thể tách khỏi sản phẩm sẽ dẫn đến việc trừu tượng hóa quá sớm và lạm dụng design pattern
Tất nhiên, tách biệt mối quan tâm, phân lớp sạch giữa business domain với những thứ như persistence/network/UI là đúng
Nhưng lớp domain thì rốt cuộc vẫn khó tránh khỏi việc bị gắn rất chặt với sản phẩm
Tôi nghĩ không có cách nào né được điều đó
Có lẽ ý ở đây là có một lớp bề mặt để thu hút người mua, còn thứ thực sự vận hành bên trong thì không phải điều người mua quan tâm
Giữa hai lớp đó có thể có một vài khái niệm đóng vai trò giao diện, nhưng cách phần bên trong tiến hóa thì nên được tách khỏi lớp sản phẩm bên ngoài
Hiện tôi đang thiết kế lại bếp, và tôi thấy ba ràng buộc này có thể khá hữu ích cho cả những công việc thiết kế tổng quát hơn chứ không chỉ phần mềm
Tôi cũng định thử áp dụng ngay
Có thể hơi đơn giản quá, nhưng nếu nhìn theo không gian và luồng thì lại thú vị hơn
Có thể nghĩ tới luồng di chuyển của con người, luồng ánh sáng, luồng thực phẩm, hay các chuyển tiếp, nên khá hay đấy
Có lẽ vì hợp với giá trị quan và gu của tôi nên tôi thấy nội dung này hay.
(Thực ra là để đánh dấu thôi)