Feature Impact Review
Mẫu & ví dụ Evaluation TemplatesMột trang, 6–12 tuần sau ra mắt, gửi người đã duyệt đầu tư: đã cược gì, kết quả ra sao, quyết định gì tiếp, và ước tính ban đầu lệch ở đâu.
Mẫu này giúp bạn
Hiểu rằng một tính năng đã ra mắt là một khoản đầu tư cần được đối chiếu với ước tính ban đầu, và kết quả đó phải gửi lại cho chính người đã duyệt.
Viết review một trang 6–12 tuần sau ra mắt: chép khoản cược từ PRD, đặt thực tế cạnh từng thành phần của chuỗi giá trị, tính đủ chi phí xây và vận hành, nêu điều bất ngờ, đề xuất giữ, cải tiến, định vị lại hay khai tử, và ghi ước tính đã lệch ở đâu để hiệu chỉnh hệ số lạc quan của đội.
Mẫu, ví dụ đã điền và cách dùng
Feature Impact Review dùng để làm gì?
Feature Impact Review đóng vòng lặp của một khoản đầu tư. Trước khi xây, ai đó đã duyệt một ước tính: tính năng này sẽ đáng chừng này tiền, tốn chừng này người-tuần. Review là lúc đặt ước tính đó cạnh thực tế, gửi lại cho chính những người đã duyệt, và nói rõ giữ, cải tiến, định vị lại hay khai tử.
Nó khác readout ở hai chỗ. Readout hỏi "lần ra mắt có ổn không?"; review hỏi "khoản cược có đáng không?" — nên nó tính cả chi phí đã bỏ ra và chi phí sẽ còn tốn để duy trì. Và review có một mục không tài liệu nào khác có: ước tính ban đầu lệch bao nhiêu, và lệch vì giả định nào.
Mục cuối đó là lý do đáng viết review dù kết quả tốt hay xấu. Sau năm bản review, đội có dữ liệu về việc mình thường lạc quan bao nhiêu — ở phạm vi, ở mức thay đổi hành vi, ở công sức. Đó là thứ biến các lần ước tính giá trị sau từ đoán thành có căn cứ, và làm người duyệt ngân sách tin bạn hơn.
Dành cho: PM · Head of Product · Growth PM · Product Owner · người duyệt đầu tư ban đầu (Business sponsor, Tài chính)
Dùng khi: 6–12 tuần sau khi tính năng tới toàn bộ đối tượng, hoặc sau một chu kỳ nhu cầu đầy đủ — đủ lâu để giữ chân và chỉ số kinh doanh có hình. Ngày review nên được ghi ngay trong PRD, ở phần giá trị kinh doanh.
Review khác gì với readout và scorecard?
| Câu hỏi | Người đọc chính | |
|---|---|---|
| Readout 2 và 6 tuần | Lần ra mắt có đạt mục tiêu không, cần sửa gì gấp? | Đội và Head of Product |
| Feature scorecard | Tính năng đang khoẻ tới đâu, điểm nghẽn ở lăng kính nào? | PM, đội, bảng tổng hợp quý |
| Feature Impact Review | Khoản cược có đáng không, và ta đã ước tính sai ở đâu? | Người đã duyệt đầu tư |
Review dùng lại số từ scorecard và readout; nó không đo lại. Phần mới là đặt các con số đó cạnh ước tính và chi phí đã được duyệt.
Bản trắng — copy và dán vào tài liệu của bạn
Một trang, năm mục. Viết cùng data analyst. Mục 1 chép nguyên văn từ PRD, không sửa lại cho đẹp.
FEATURE IMPACT REVIEW — [Tên tính năng]
Ngày ra mắt: ...... Ngày review: ...... Người viết: ......
Gửi tới (người đã duyệt đầu tư): ......
1. CHÚNG TA ĐÃ CƯỢC GÌ (chép từ PRD duyệt ngày ......)
Vấn đề: ......
Đối tượng (định nghĩa đo được): ......
Chuỗi giá trị ước tính:
Phạm vi: ...... người hoặc khách/tháng
Thay đổi hành vi: ...... mỗi người/tháng
Giá trị mỗi hành vi: ......đ (lãi gộp)
Ước tính: thấp ...... / giữa ...... / cao ...... mỗi tháng
Chi phí ước tính: xây ...... người-tuần; vận hành ......đ/tháng
2. KẾT QUẢ
Thành phần | Ước tính (giữa) | Thực tế | Nguồn / cách so sánh
Phạm vi | ...... | ...... | ......
Thay đổi hành vi | ...... | ...... | ......
Giá trị mỗi hành vi | ...... | ...... | ......
Giá trị/tháng | ...... | ...... | ......
Chi phí xây | ...... | ...... | ......
Chi phí vận hành/tháng| ...... | ...... | ......
Bốn lăng kính (từ scorecard): đối tượng ...... dùng thử ......
giữ chân ...... hài lòng ......
Hoàn vốn: ...... tháng (ước tính ban đầu: ...... tháng)
3. ĐIỀU BẤT NGỜ
Ai dùng mà ta không dự kiến: ......
Ai không dùng mà ta tưởng sẽ dùng: ......
Tác động phụ, tốt hoặc xấu, lên chỉ số khác: ......
4. QUYẾT ĐỊNH ĐỀ XUẤT: GIỮ / CẢI TIẾN / ĐỊNH VỊ LẠI / KHAI TỬ
Lý do: ......
Việc tiếp theo | Người | Hạn | Chi phí thêm
......
Cần người nhận review duyệt: ......
5. BÀI HỌC CHO LẦN ƯỚC TÍNH SAU
Thành phần lệch nhiều nhất: ...... (ước tính ...... / thực tế ......)
Vì giả định nào: ......
Lần sau kiểm giả định đó bằng: ......
Hệ số lạc quan của đội (cộng dồn các review): ......Từng ô điền gì, và vì sao ô đó tồn tại
| Ô | Điền gì | Bỏ trống thì hỏng ở đâu |
|---|---|---|
| Chép từ PRD, có ngày | Nguyên văn vấn đề, đối tượng, chuỗi giá trị, chi phí ước tính lúc được duyệt. | Viết lại khoản cược sau khi đã biết kết quả thì nó luôn khớp với kết quả. Ngày PRD là bằng chứng không ai sửa. |
| Chuỗi giá trị | Phạm vi × thay đổi hành vi × giá trị mỗi hành vi, ở ba mức. | Không tách thành từng thành phần thì chỉ biết "lệch 60%", không biết lệch ở đâu, và không học được gì. |
| Thực tế theo từng thành phần | Con số thực tế của từng mắt xích, đặt cạnh ước tính. | Đây là chỗ thấy ước tính sai vì phạm vi (ít người đi qua hơn) hay vì hành vi (người ta thay đổi ít hơn) — hai bài học rất khác nhau. |
| Nguồn / cách so sánh | Nhóm đối chứng, trước-sau, hay ước lượng — ghi rõ. | Tài chính sẽ hỏi. Một con số không có cách so sánh là con số họ sẽ chiết khấu về 0. |
| Chi phí thực tế | Người-tuần đã tiêu, kể cả thiết kế, QA, pháp chế, vận hành; chi phí chạy hằng tháng. | Chỉ so giá trị mà không so chi phí thì không trả lời được câu "có đáng không". |
| Hoàn vốn | Số tháng để giá trị ròng bù chi phí xây, so với ước tính ban đầu. | Đây là con số người duyệt đầu tư nhớ. Không có nó, review không trả lời đúng câu hỏi của họ. |
| Điều bất ngờ | Người dùng không dự kiến, tác động phụ lên chỉ số khác. | Nhiều khi giá trị thật của một tính năng nằm ở chỗ không ai tính trước — và chi phí ẩn cũng nằm ở đó. |
| Quyết định đề xuất | Một trong bốn quyết định, kèm việc tiếp theo và chi phí thêm. | Review không có quyết định chỉ là báo cáo; người đọc không biết mình đang được yêu cầu làm gì. |
| Bài học cho lần ước tính sau | Thành phần lệch nhiều nhất, giả định gây lệch, cách kiểm lần sau, hệ số lạc quan cộng dồn. | Mục bị bỏ trống nhiều nhất và có giá trị nhất. Không có nó, đội lặp lại đúng sai lầm ước tính đó ở tính năng tiếp theo. |
Cách viết và gửi review
- Lấy PRD gốc, chép mục 1 nguyên văn. Nếu PRD không có ước tính giá trị, ghi "không có ước tính trước" — đó sẽ là bài học số một của bản review này.
- Lấy số bốn lăng kính từ scorecard, kết quả từ readout 6 tuần. Không đo lại những gì đã có; review là nơi ghép, không phải nơi đào.
- Điền thực tế cho từng thành phần của chuỗi giá trị. Nhờ data cho phạm vi và hành vi; nhờ tài chính cho giá trị mỗi hành vi và chi phí vận hành thật.
- Tính chi phí xây thực tế bằng cách hỏi từng nhóm đã động tay: thiết kế, QA, pháp chế, CS, đội triển khai. Phần ngoài dev thường bị quên và có thể bằng một nửa chi phí dev.
- Viết mục 5 trước mục 4. Khi đã rõ mình ước tính sai ở đâu, quyết định tiếp theo thường tự hiện ra.
- Đưa cho người hoài nghi nhất đọc trước — thường là người bên tài chính. Sửa theo câu hỏi đầu tiên của họ.
- Gửi cho đúng người đã duyệt đầu tư, kèm một câu hỏi cụ thể cần họ trả lời. Cập nhật hệ số lạc quan của đội vào một trang dùng chung.
Ví dụ đã điền đầy đủ
ĐặtKhám (giả định) là phần mềm đặt lịch và quản lý cho khoảng 1.400 phòng khám tư, thu phí theo tháng. Tính năng "Nhắc tái khám qua Zalo" tự gửi tin nhắc bệnh nhân trước lịch tái khám bác sĩ đã hẹn. Được duyệt tháng 1 với ước tính giảm tỉ lệ phòng khám huỷ gói. Review viết 10 tuần sau khi bật cho toàn bộ. Chi phí quy đổi 30 triệu mỗi người-tuần.
FEATURE IMPACT REVIEW — Nhắc tái khám qua Zalo
Ngày ra mắt: 04/03 (100%) Ngày review: 13/05
Người viết: Trâm (PM), Kiên (Data)
Gửi tới: anh Hưng (CEO), chị Mỹ (Giám đốc tài chính)
1. CHÚNG TA ĐÃ CƯỢC GÌ (PRD duyệt 15/01)
Vấn đề: 38% bệnh nhân được hẹn tái khám không quay lại; phòng khám
mất doanh thu và so sánh chúng ta với đối thủ có tính năng nhắc.
Đối tượng: phòng khám có ít nhất 50 lượt hẹn tái khám/tháng — 900
phòng khám
Chuỗi giá trị (cho ĐặtKhám):
Phạm vi: 900 phòng khám bật tính năng
Thay đổi hành vi: tỉ lệ huỷ gói giảm từ 2,5% xuống 1,8%/tháng
(thấp: xuống 2,2% / cao: xuống 1,5%)
Giá trị mỗi hành vi: một phòng khám giữ lại = lãi gộp 1,1 triệu
× 30 tháng = 33 triệu
Ước tính: thấp 89 / giữa 208 / cao 297 triệu mỗi tháng
Chi phí ước tính: xây 14 người-tuần (420 triệu);
vận hành 18 triệu/tháng (phí tin nhắn)
Hoàn vốn ước tính: khoảng 2 tháng
2. KẾT QUẢ
Phạm vi
Ước tính 900 | Thực tế 610 phòng khám bật | đếm trực tiếp
Hành vi của bệnh nhân (không có trong ước tính)
Tỉ lệ quay lại tái khám 62% lên 71% | 120 phòng khám đối chứng, 4 tuần
Hành vi: huỷ gói
Ước tính 2,5% xuống 1,8% | Thực tế 2,5% xuống 2,1%
| đối chứng 4 tuần, sau đó trước-sau
Giá trị mỗi phòng khám giữ lại
Ước tính 33 triệu | Thực tế 33 triệu | tài chính xác nhận
Giá trị/tháng
Ước tính 208 triệu | Thực tế 81 triệu (610 × 0,4% × 33 triệu)
Chi phí xây
Ước tính 14 người-tuần | Thực tế 23 người-tuần (690 triệu), gồm
pháp chế và duyệt mẫu tin với Zalo
Chi phí vận hành/tháng
Ước tính 18 triệu | Thực tế 41 triệu (tin nhắn + đối soát)
Bốn lăng kính: đối tượng 900 | dùng thử (bật và gửi ≥ 20 tin) 68% |
giữ chân tuần 8: 93% | hài lòng chủ phòng khám 4,6 (n = 214)
Hoàn vốn: khoảng 17 tháng (81 - 41 = 40 triệu ròng/tháng)
— ước tính ban đầu: khoảng 2 tháng
3. ĐIỀU BẤT NGỜ
- 290 phòng khám không bật vì cần bệnh nhân đồng ý nhận tin; chưa ai
thiết kế quy trình xin đồng ý tại quầy lễ tân.
- Phòng khám nha và nhi gửi gấp 3 lần dự kiến vì lịch tái khám dày —
chi phí tin nhắn vượt ước tính chủ yếu vì họ.
- Tác động phụ tốt: doanh thu tái khám của phòng khám tăng khoảng 9%;
đội sales đã dùng con số này trong 14 deal mới.
4. QUYẾT ĐỊNH ĐỀ XUẤT: CẢI TIẾN
Lý do: giá trị cho phòng khám rõ ràng (giữ chân tính năng 93%, bệnh
nhân quay lại hơn 9 điểm); giá trị cho ĐặtKhám thấp hơn ước tính vì
phạm vi và vì chi phí tin nhắn — cả hai sửa được.
Việc tiếp theo:
- Luồng xin đồng ý tại quầy + mẫu giấy in Trâm, 30/06, 3 người-tuần
- Gói tin nhắn tính phí riêng cho phòng khám gửi trên 2.000 tin/tháng
Trâm + tài chính, 15/07
Cần duyệt: chị Mỹ duyệt mô hình phí tin nhắn trước 31/05.
5. BÀI HỌC CHO LẦN ƯỚC TÍNH SAU
Lệch nhiều nhất: phạm vi (900 / 610) và chi phí vận hành (18 / 41 triệu).
Vì giả định nào: coi "đủ điều kiện" là "sẽ bật" — bỏ qua bước bệnh
nhân phải đồng ý; tính phí tin nhắn theo tần suất trung bình, không
theo nhóm chuyên khoa dùng nhiều nhất.
Lần sau kiểm bằng: gọi 10 phòng khám hỏi họ phải làm thêm gì trước
khi bật; ước tính chi phí biến đổi theo nhóm dùng nhiều nhất.
Hệ số lạc quan của đội (4 review gần nhất): giá trị thực tế khoảng
45% ước tính giữa; chi phí xây thực tế khoảng 1,5 lần ước tính.Điều làm review này có giá trị không phải con số 81 triệu, mà là việc nó chỉ ra chính xác ước tính sai ở đâu. Mức thay đổi hành vi gần đúng: huỷ gói giảm 0,4 điểm so với dự kiến 0,7 — vẫn nằm giữa mức thấp và mức giữa. Cái sai lớn là phạm vi và chi phí biến đổi, hai thứ kiểm được rất rẻ trước khi xây bằng mười cuộc gọi và một bảng tính theo nhóm chuyên khoa. Lần tới đội ước tính một tính năng gửi tin nhắn, chị Mỹ sẽ hỏi đúng hai câu đó — và đội đã có sẵn câu trả lời.
Hiccups thường gặp và cách xử lý
| Hiccup | Vì sao xảy ra | Xử lý |
|---|---|---|
| Viết lại khoản cược cho khớp kết quả | Muốn review trông tốt | Chép nguyên văn từ PRD có ngày duyệt; nếu không có PRD, ghi rõ điều đó. |
| Chỉ so giá trị, không so chi phí | Chi phí nằm rải rác ở nhiều nhóm, khó gom | Hỏi từng nhóm đã động tay; thêm chi phí vận hành thực tế hằng tháng. |
| Kết luận từ tương quan | Khách dùng tính năng vốn đã gắn bó hơn | Dùng nhóm đối chứng nếu có; nếu không, so trước-sau, chiết khấu, và ghi rõ. |
| Bỏ trống mục bài học | Ngại thừa nhận đã ước tính sai | Viết mục 5 trước mục 4; ước tính sai là dữ liệu, không phải lỗi cá nhân. |
| Gửi cho đội thay vì người duyệt | Review bị coi là tài liệu nội bộ | Gửi đúng người đã duyệt đầu tư, kèm một câu hỏi họ cần trả lời. |
| Chỉ review tính năng thành công | Tính năng thất bại bị lặng lẽ bỏ qua | Review mọi tính năng có ước tính trong PRD; tính năng thất bại dạy nhiều hơn. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| PM | Đóng vòng lặp với người duyệt đầu tư, và xây uy tín cho các lần xin nguồn lực sau bằng ước tính đã được hiệu chỉnh |
| Head of Product | Theo dõi hệ số lạc quan của các đội qua nhiều review, và chiết khấu ước tính mới cho phù hợp |
| Growth PM | Tìm tác động phụ và nhóm người dùng bất ngờ — thường là nơi có cơ hội tiếp theo |
| Product Owner | Biến quyết định cải tiến hoặc khai tử thành việc trong backlog, có chi phí thêm đã được duyệt |
| Business sponsor / Tài chính | Biết khoản đầu tư đã duyệt ra sao, và có căn cứ để duyệt hoặc từ chối chi phí thêm |
Definition of done
- Mục 1 chép nguyên văn từ PRD, có ngày duyệt.
- Mỗi thành phần của chuỗi giá trị có ước tính, thực tế và cách so sánh.
- Chi phí xây và vận hành thực tế được tính đủ, không chỉ phần dev.
- Có thời gian hoàn vốn, đặt cạnh ước tính ban đầu.
- Có quyết định đề xuất với việc tiếp theo, người, hạn và chi phí thêm.
- Mục bài học chỉ ra thành phần lệch nhiều nhất, giả định gây lệch, và hệ số lạc quan được cập nhật.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.