The Chain of Creation: Làm Product Không Phải Chỉ Viết Yêu Cầu Mà Là Kết Nối Tầm Nhìn và Thực Thi
Great products are built when Why, What và How di chuyển nhịp nhàng, không dư một bước
Gần đây, mình tiếp xúc với khá nhiều intern và các bạn trẻ mới bắt đầu con đường phát triển Product, mình nhận ra rằng mọi người đang gặp khó khăn trong việc hình dung bức tranh toàn cảnh.
Rất nhiều bạn lao vào viết user story, thiết kế wireframe hay test sản phẩm, nhưng lại thiếu mất phần gốc: Tại sao product này cần được xây dựng? Nó sẽ phục vụ mục tiêu nào?
Một số bạn BA sẽ dành nhiều thời gian để viết các tài liệu thật chi tiết, nhưng không biết đâu là điểm dừng, và không kết nối được giữa business objective và hành động cụ thể cho dev.
Đó là lý do mình muốn chia sẻ bài viết này “The Chain of Creation” - một cách tiếp cận không mới nhưng vô cùng cần thiết nếu bạn muốn trở thành Product Manager thực thụ, chứ không chỉ dừng lại ở vai trò viết document.
Sự trưởng thành trong nghề Product đến từ việc bạn hiểu sâu ở các tầng khác nhau như Why → What → How → Who. Và bạn giữ cho team luôn rõ ràng ở bất kỳ tầng nào.
The Chain of Creation
The Chain of Creation mô tả một quy trình chuyển hoá một ý tưởng kinh doanh thành một hành động cụ thể trong phát triển phần mềm. Đây là chuỗi liên kết sẽ giúp PM hay BA đảm bảo rằng:
Tầm nhìn từ phía Business được hiểu đúng
Được chuyển thành sản phẩm đúng
Và được xây dựng một cách hiệu quả
Đây là một quy trình gồm 5 tầng mà một PM nên hiểu rõ: Từ ý tưởng kinh doanh (BRD) → xác định sản phẩm cần xây dựng (PRD) → chi tiết kỹ thuật (FSD) → chuyển thành nhu cầu người dùng (User Story) → chia thành công việc cụ thể (Task/ Sub-task)
Tóm lại, nếu bạn kết nối mạch lạc giữa BRD → Task liền mạch, đội ngũ sẽ hiểu vì sao họ code, QA sẽ test đúng giá trị và stakeholder sẽ nhìn thấy ROI.
Grey Areas - 4 điểm mờ và cách xử lý
Trong suốt 8 năm làm việc trong lĩnh vực IT/ Tech, phát triển kha khá các dự án phần mềm, cá nhân mình cũng đã đúc kết ra những kinh nghiệm mà mình nghĩ sẽ đem lại giá trị cho mọi người
BRD vs PRD
Vấn đề cả hai cùng mô tả mục tiêu phạm vi, dễ gây trùng lặp. Lúc mới làm PM, mình thường viết PRD thật kỹ, chi tiết từng field, từng logic. Kết quả thì sao, dev thấy rối và team confused vì không biết phải đọc thêm tài liệu nào.
BRD = Why = Mục tiêu kinh doanh (Tương tự góc nhìn trong Agile là Epic)
PRD = What = Sản phẩm cụ thể phải làm gì (Tương tự góc nhìn trong Agile là Feature)
PRD vs FSD
PRD đôi khi đi quá sâu, sẽ chồng chéo lên FSD, giải pháp ở đây đó là:
PRD = hãy tập trong các high-level feature, user flow, wireframe tổng thể
FSD = sẽ đi sâu vào chi tiết kỹ thuật như UI Flow của từng feature, APIs, validation rules.
FSD vs User Story
Việc nhồi nhét quá nhiều chi tiết kỹ thuật vào Story cũng sẽ khiến mất đi góc nhìn từ người dùng. Vì thế:
FSD = Technical specs
User Story = User need “As a user, I want…”
User Story vs Task
Nhầm lẫn giữa giá trị và nhu cầu người dùng với công việc cụ thể.
Story = Giá trị mang lại cho user
Task = Công việc cụ thể phải làm để deliver giá trị đó
Một lần mình nhận được story kiểu:
“Create whitelist API and button”
Dev làm đúng nhưng quên mất người dùng sẽ lưu được nhiều sản phẩm, và cần đồng bộ đa thiết bị. Mình nhận ra story đó đang viết task dưới dạng story, và thiếu góc nhìn từ người dùng.
Story nên là:
“As a user, I want to save favorite products so I can view them across devices”
Còn task mới là:
API để lưu product
UI button
Đồng bộ multi-device
Tổng kết lại bằng một bảng sau để dễ đọc nhé mọi người:
Chain of Creation trong Waterfall & Agile
Sự chuyển dịch BRD, PRD, FSD sang Agile như thế nào
Nếu ở Waterfall chúng ta đã quen thuộc với BRD, PRD, FSD thì trong Agile, những khái niệm này được rút gọn và chuyển hoá thành các mảnh nhỏ hơn, linh hoạt hơn như Epic, User Story và Task. Thay vì viết tài liệu hàng chục trang khi bắt đầu phát triển, Agile khuyến khích phát triển liên tục và tập trung vào việc giao tiếp trong team, phản hồi người dùng và giá trị thực tiễn.
Bên dưới là cấu trúc Chain of Creation trong Agile
BRD → Epic: Thay vì mô tả chi tiết tất cả yêu cầu, hãy dùng Epic để nói về mục tiêu kinh doanh
PRD → Feature/ Capability: Viết ở mức high-level. Sau đó cùng team refine thành User Stories theo từng Sprint.
FSD (rút gọn) → User Stories: Rút gọn FSD và cụ thể hoá nhu cầu người dùng, mô tả hành vi
FSD (chi tiết) → Acceptance Criteria + Technicals Note: Điều kiện hoàn thành, rule, API, validation, cần rõ ràng ngắn gọn và chi tiết hướng tới việc solution, cùng Dev + QA + PM refine trong Sprint Planning hoặc Story Grooming.
Task/ Subtask (giữ nguyên): Công việc cụ thể cần thực hiện của Dev, Design, QC, etc.
Đối với Waterfall mọi thứ sẽ luôn là “Big Design Up Front” ví dụ như viết tài liệu chi tiết từ đầu, tài liệu đòi hỏi toàn diện, cố định, thiết kế giải pháp trước khi code và delivery thông qua tài liệu.
Nhưng với Agile, có thể tổ chức từ Epic → Feature → User Story theo thời gian các sprint. Tài liệu thì yêu cầu gọn nhẹ, có thể thay đổi theo từng Sprint. Và thiết kế thì vừa đủ để có thể phát triển “Just Enough, Just in Time” và có thể chuyển giao thông qua tương tác và workshop.
Vấn đề thường gặp khi chuyển từ Waterfall sang Agile
Tuy nhiên, rõ ràng sự thay đổi này là không hề đơn giản, một số vấn đề có thể xảy ra:
Vẫn viết tài liệu dài nhưng gọi là Agile PRD → Mình gặp khá nhiều tiêu vẫn là Waterfall disguised as Agile, kiểu vẫn làm rất đầy đủ chi tiết và cho rằng họ đang sử dụng Agile dẫn đến sau 2 tháng vận hành vẫn chưa tạo ra được dòng code nào.
Không rõ ranh giới giữa Epic và User Story → Có một điều khá khó để định hình Epic trong Agile Scrum, nó sẽ nên là nhóm chức năng hay một chức năng, có thể break down được nữa không? Điều đó dẫn đến backlog bị rối, không biết phải bắt đầu từ đâu.
Thiếu Just Enough Design cho team kỹ thuật → Dev hiểu sai yêu cầu vì không đủ thông tin kỹ thuật.
Just Enough, Just in Time - 3 nguyên tắc vàng
Epic & Feature chỉ nói điểm đích — không trượt sâu vào giải pháp.
Story tập trung ngữ cảnh người dùng — mọi chi tiết kỹ thuật để ở tầng Criteria/Notes.
Criteria đủ rõ để Dev code ngay — nhưng không biến thành “bản FSD 20 trang”.
Case Study: Wishlist for Favorite Product in E-commerce
Để so sánh góc nhìn của sự chuyển đổi Waterfall (BRD, PRD, FSD) sang Agile (Epic, User Story, Task) thông qua một tính năng đơn giản là Wishlist - Lưu sản phẩm yêu thích trong một ứng dụng E-commerce.
Waterfall Approach
Đầu tiên hãy bắt đầu với Waterfall Approach nhé.
BRD - Business Requirements Document
Mục tiêu kinh doanh:
Tăng tỉ lệ quay lại và thời gian phiên truy cập của người dùng bằng cách cho phép họ lưu lại sản phẩm yêu thích để dễ dàng truy cập sau này.
PRD - Product Requirements Document
Tính năng đề xuất:
Người dùng có thể nhấn nút “❤️” để lưu sản phẩm vào danh sách yêu thích.
Danh sách sản phẩm yêu thích được hiển thị trong trang cá nhân.
Chỉ người dùng đăng nhập mới có thể sử dụng tính năng này.
FSD - Functional Specification Document
Technical Flow:
Khi người dùng nhấn ❤️:
Gửi API POST /wishlist kèm theo product_id và user_id.
Trả về trạng thái thành công.
Trong profile, gọi API GET /wishlist để hiển thị danh sách sản phẩm yêu thích.
Nếu người dùng chưa đăng nhập, popup hiện ra yêu cầu login.
Icon ❤️ sẽ đổi màu khi sản phẩm đã được yêu thích.
Agile Approach
Epic
As a business owner, I want users to save favorite products so they can revisit them later, leading to better engagement and retention.
User Stories
US-01: As a logged-in user, I want to click a heart icon on a product so I can save it to my wishlist.
Acceptance Criteria: Heart icon toggles state & Saved products persist after reload.
US-02: As a user, I want to view all my wishlist items in one place.
Acceptance Criteria: in one place. List shows correct products & Link from homepage/profile
US-03: As a guest, I should be prompted to log in when trying to use the wishlist feature.
Acceptance Criteria: Non-logged-in users get login prompt & No wishlist action without login
Task for US-01
FE: Implement ❤️ toggle component
FE: Add conditional rendering based on whitelist state
BE: Create
POST/wishlistandDELETE/wishlist APIsQA: Write test cases for wishlist API & UI behavior
Lợi ích của Agile
PM không cần chờ viết xong toàn bộ tài liệu → có thể cùng team bắt đầu từ Epic và viết User Stories trong từng Sprint.
Dev và QA dễ hiểu yêu cầu vì mỗi story rõ ràng, có tiêu chí hoàn thành cụ thể.
Có thể release tính năng Wishlist theo từng phase: lưu trước, xem sau, đồng bộ sau → tăng tốc việc ra mắt sản phẩm.
Tổng Kết
Agile không phủ nhận giá trị của BRD - PRD - FSD. Thay vào đó, Agile giữ lại tinh thần của chúng, nhưng chia nhỏ linh hoạt và tập trung hơn vào giao tiếp & giá trị người dùng.
Hy vọng qua bài viết này chúng ta sẽ hiểu rõ hơn về Chain of Creation trong Waterfall và Agile, hiểu và ứng dụng sẽ mang lại giá trị cho bạn. Để lại comment hoặc reply bài viết này nếu bạn có bất kỳ câu hỏi hoặc chia sẻ nào nhé. Mình rất sẵn lòng chia sẻ và lắng nghe mọi người!