Startup làm product tinh gọn: Rõ từng thực thể, dễ mở rộng về sau
Startup làm product tinh gọn: tách rõ Topic và Post, đáp ứng nhu cầu hiện tại, rồi ghép thành workflow khi nghiệp vụ rõ hơn để dễ mở rộng.

Khi làm sản phẩm cho startup, chúng ta thường phải đi nhanh, dù chưa nhìn rõ toàn bộ bức tranh. Yêu cầu hôm nay có thể chỉ là đăng một bài viết. Tháng sau, khách hàng đã muốn phân công người viết, duyệt nội dung và lên lịch xuất bản.
Vậy nên bắt đầu thế nào để dễ thay đổi về sau?
Hãy lấy một công cụ quản lý nội dung làm ví dụ.
Khách hàng là một công ty tuyển dụng. Họ muốn chia sẻ kinh nghiệm tìm việc trên website, với những chủ đề như chuẩn bị hồ sơ, phỏng vấn và định hướng nghề nghiệp.
Ở đây, chúng ta có hai thực thể: Topic, tức chủ đề, và Post, tức bài viết.
Topic dùng để nhóm những nội dung liên quan. Chẳng hạn, chủ đề “Kinh nghiệm phỏng vấn” có thể chứa nhiều bài viết và tiếp tục được sử dụng trong nhiều năm.
Post là một bài cụ thể, như “Cách giới thiệu bản thân khi phỏng vấn”. Mỗi bài có nội dung, người viết và trạng thái riêng.
Hiểu như vậy, phiên bản đầu tiên có thể rất đơn giản: một nơi quản lý chủ đề, một nơi quản lý bài viết. Muốn viết bài, người dùng chọn một chủ đề đã có, nhập nội dung rồi lưu nháp hoặc xuất bản.
Sau hai tháng, công ty có thêm người viết. Họ muốn chuẩn bị sáu bài về phỏng vấn, giao cho từng người và đăng mỗi tuần một bài.
Nếu hai thực thể đã được tách rõ, chúng ta có thể bổ sung người phụ trách, trạng thái duyệt và lịch đăng cho từng bài. Sau đó, tạo một màn hình giúp khách hàng chọn chủ đề, thêm nhiều bài và phân công cùng lúc.
Workflow lúc này được xây từ nhu cầu thực tế, trên những thành phần đã có.
Nhưng hãy thử hình dung một cách làm khác.
Ngay từ đầu, sản phẩm bắt người dùng đi qua một luồng cố định: tạo chủ đề, viết một bài, chọn ngày đăng rồi hoàn tất. Chủ đề và bài viết chỉ được lưu khi làm xong tất cả.
Khi đó, muốn tạo trước chủ đề cũng phải nhập một bài. Muốn chuẩn bị sáu bài chưa có nội dung, hệ thống lại chưa hỗ trợ. Nếu lịch đăng được lưu chung cho cả luồng, chúng ta còn phải chuyển nó về từng bài.
Một yêu cầu mới kéo theo việc sửa nhiều phần, vì những thành phần vốn có vòng đời riêng đã bị gắn chặt vào một trình tự.
Điều này không có nghĩa cứ nhiều bước là phức tạp. Một giao diện nhiều bước vẫn có thể được xây trên các thực thể độc lập. Điểm cần tránh là biến cách thao tác ban đầu thành ràng buộc cho cả hệ thống.
Với startup, tinh gọn có thể bắt đầu từ việc hiểu rõ từng thực thể, xác định quan hệ giữa chúng và làm đủ cho nhu cầu hiện tại.
Khi bức tranh lớn dần rõ hơn, chúng ta ghép các thành phần thành workflow phù hợp. Và nếu cần tạo nhanh chủ đề ngay trong form bài viết, vẫn có thể bổ sung.
Giữ nền tảng rõ ràng từ đầu giúp đội ngũ đi nhanh hôm nay và dễ điều chỉnh ngày mai.
