- 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 việc trôi đến một kết quả quá phức tạp hoặc không có bản sắc
- Mọi ý tưởng đều phải được tóm gọn trong một one pager; nếu không thể chứa trong đó thì nên xem như vẫn cần thêm nghiên cứu, lập kế hoạch và làm prototype
- Cần xây dựng core tech có thể tồn tại độc lập với sản phẩm, để dù có xoay hướng vẫn tiếp tục tích lũy thành tài sản tích lũy
- Ở trung tâm sản phẩm phải có một defining constraint luôn hiện rõ với người dùng; chính ràng buộc này sẽ tự nhiên định hình feel và bản sắc của sản phẩm
- Nếu không vượt qua được dù chỉ một trong ba tiêu chí thì không nên làm; thái độ đó rất 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 cần đặt ra trước khi bắt tay vào làm
- Trước khi làm sản phẩm, nếu đặt ràng buộc trước thì không gian khám phá sẽ thu hẹp lại và tránh việc trôi đến một kết quả quá phức tạp hoặc không có bản sắc
- Trong 10 năm làm nhiều sản phẩm khác nhau, các sản phẩm quá phức tạp hoặc thiếu bản sắc đều dẫn đến thất bại, và sau những lần thử sai đó mọi thứ được nén lại 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ò như 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 để giao tiếp với nhiều đối tượng như nhà đầu tư, cộng tác viên, thành viên trong nhóm, bạn bè và gia đình
- Khi phát sinh xung đột trong quá trình 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ì cần sửa tài liệu để phản ánh điều đó
- Nếu chưa thể lấp đầy một trang thì không phải là cố bơm thêm nội dung, mà nên xem như vẫn chưa sẵn sàng để làm
- Trong trường hợp đó, trước tiên cần đi qua các bước nghiên cứu, lập kế hoạch, prototype rồi viết lại one pager
- Nếu dài đến mức vượt quá một trang thì nghĩa là quá phức tạp, nên không làm
-
Công nghệ cốt lõi phải tách biệt khỏi sản phẩm
- Tách khỏi bản thân sản phẩm, cần xây dựng core tech nâng đỡ 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 có thể tồn tại kể 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 thay đổi hướng liên tục, nhưng core tech sẽ còn lại như một tài sản bền vững và tích lũy
- Về dài hạn, nỗ lực tích lũy kiểu này có thể tạo ra lợi ích phi tuyến
- Các ví dụ được nêu gồm git của Linus Torvalds, HCL của HashiCorp, và 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à core tech
- Core tech phải độc lập với hướng đi của sản phẩm, nhưng vẫn cần 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 thể tạo điều kiện cho core tech, thì nó không có đủ đòn bẩy
-
Một ràng buộc mang tính quyết định phải định nghĩa sản phẩm
- Ở trung tâm của sản phẩm phải có một defining constraint luôn hiển hiện 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 đối mặt và tương tác cùng, và chính nó tạo ra bản sắc cho sản phẩm
- Một ràng buộc tốt sẽ tạo nên 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ỉ từ các khối, còn IKEA có bản sắc là đồ nội thất flat-pack tự lắp ráp; ở đó bản sắc lộ ra 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 quyết định để giới hạn phạm vi và giúp tập trung vào những 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ả
- 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 theo 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 nhất trong one pager
Tiêu chí kết luận
- Nếu không vượt qua được dù chỉ một trong ba ràng buộc thì không làm
1 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