Case Study: Startup SaaS 20 người
Mẫu & ví dụ Product OKR Case StudiesStartup SaaS cắt roadmap từ 15 features xuống 4 initiatives bằng activation OKR.
Mẫu, ví dụ đã điền và cách dùng
Case Study: Startup SaaS 20 người
Case này cho thấy OKR giúp startup thoát khỏi founder-led feature list và tập trung vào activation evidence.
Business context và pain
| Business context | Startup SaaS 20 người có nhiều trial signups nhưng paid conversion thấp. Founder muốn ship 15 features vì nghe nhiều customer requests. |
| User/stakeholder pain | Team Engineering quá tải, roadmap đổi mỗi tuần, Sales nói thiếu feature, Product không biết feature nào thật sự giúp trial convert. |
| Evidence observed | Trial users bỏ trước khi hoàn thành setup; 43% support tickets hỏi về first workflow; activated trials convert cao gấp 3 lần non-activated trials. |
| Assumptions | Nếu giảm setup friction và giúp users thấy value trong 24 giờ, trial-to-paid sẽ tăng. |
| Open questions | Activation event nào thật sự predict paid conversion? Segment nào có conversion tốt nhất? Setup friction lớn nhất ở bước nào? |
OKR structure và decisions
| Objective | Help qualified trial users experience core workflow value before trial ends. |
| KR 1 | Activation rate 38% -> 58%. |
| KR 2 | Time-to-first-value 3.2 days -> 1 day. |
| KR 3 | Trial-to-paid 9% -> 14%. |
| Final artifact | Product OKR Canvas + Roadmap-to-KR Map with 4 initiatives. |
Success metrics và cách track
| Metric | Cách đo |
|---|---|
| Activation | Qualified trial accounts completing first workflow / qualified trial accounts. |
| TTFV | Median time from signup to first workflow completed. |
| Trial-to-paid | Paid accounts / qualified trials. |
Cách triển khai trong 30-60-90 ngày
- First 30 days: define activation, instrument setup funnel, interview 10 abandoned trials.
- Days 31-60: ship guided setup, sample data and checklist; review activation weekly.
- Days 61-90: cut low-impact requests, double down on initiatives that reduce TTFV.
Pitfalls và lesson learned
- Lesson: startup speed is not shipping everything; it is learning which lever moves activation.
- No-no: accepting every founder/customer feature without evidence.
- Advanced move: segment activation by ICP and acquisition channel.
Giữa quý — con số nói gì và đội đã hiểu sai ra sao
| Tuần | Chỉ số chính | Dự kiến | Đội kết luận lúc đó |
|---|---|---|---|
| 2 | 36% | 36% | Đúng hướng, việc rút bước xác minh có tác dụng |
| 4 | 37% | 40% | "Chỉ chậm một chút, sẽ bắt kịp" |
| 6 | 37% | 44% | Bắt đầu lo, quyết định làm lại giao diện bước 3 |
| 8 | 38% | 48% | Giao diện mới ra mắt, gần như không đổi gì |
Sai lầm ở tuần 6 là sai lầm điển hình: đội thấy tỉ lệ bỏ cuộc cao nhất ở bước 3, nên kết luận bước 3 khó dùng và đi làm lại giao diện. Ba tuần công sức, gần như không có tác động.
Điều đã bị bỏ qua: không ai xem người dùng thật đi qua bước đó. Con số nói ở đâu họ rơi ra, nhưng không nói vì sao — và đội đã tự điền phần "vì sao" bằng giả định hợp lý nhất mà họ nghĩ ra.
Tuần 9 — điều tra đúng cách và điều tìm thấy
- Xem 8 phiên ghi màn hình của người dùng rơi ở bước 3.
- Phát hiện: họ không thấy bước đó khó. Họ dừng lại vì bước đó yêu cầu quyền quản trị của hệ thống công ty — thứ phần lớn người đăng ký không có.
- Nghĩa là: người dùng không thất bại. Họ đi ra để hỏi bộ phận IT, và phần lớn không bao giờ quay lại vì không có gì nhắc họ.
- Không có thay đổi giao diện nào sửa được điều này — vấn đề nằm ở giả định của sản phẩm về người dùng, không ở màn hình.
Thay đổi đã làm: cho phép bỏ qua bước kết nối và hoàn tất sau, kèm nhắc lại sau 24 giờ. Mất một tuần làm.
| Tuần | Chỉ số | Ghi chú |
|---|---|---|
| 10 | 38% | Trước thay đổi |
| 11 | 43% | Sau thay đổi — tăng 5 điểm trong một tuần |
| 12 | 47% | Kết quả cuối quý, so với mục tiêu 60% |
Bài học rút ra
- KR không đạt (47% so với 60%), nhưng quý này thành công. Đội tìm ra nguyên nhân thật và có một thay đổi đã chứng minh hiệu quả — đó là thứ mang sang quý sau được.
- Số liệu nói ở đâu, không nói vì sao. Ba tuần làm lại giao diện là cái giá của việc tự điền phần "vì sao" bằng giả định.
- Tám phiên ghi màn hình rẻ hơn ba tuần lập trình — và lẽ ra phải là việc đầu tiên làm ở tuần 6.
- Cột "dự kiến phải đạt" đã cảnh báo từ tuần 4. Đội nhìn thấy nhưng diễn giải là "chậm một chút", không phải "giả định của chúng ta có thể sai".
Áp dụng vào tình huống của bạn
Ca này lặp lại ở mọi sản phẩm có phễu. Dưới đây là cách nhận ra nó sớm.
| Bạn quan sát thấy | Đừng kết luận ngay là | Kiểm bằng cách |
|---|---|---|
| Tỉ lệ rơi cao ở một bước | Bước đó khó dùng | Xem 5–8 phiên ghi màn hình của chính những người rơi ra |
| Người dùng dừng lại rồi không quay lại | Họ không quan tâm | Hỏi: họ đi đâu? Có phải họ đi hỏi ai đó và không có gì nhắc họ quay lại? |
| Sửa giao diện không có tác dụng | Cần sửa nhiều hơn | Giả định gốc có thể sai — dừng sửa, đi tìm nguyên nhân |
| Một bước cần điều kiện bên ngoài sản phẩm | Đó là việc của người dùng | Đó là giả định của bạn về người dùng, và nó kiểm được |
Quy tắc rút ra từ ca này: khi một KR chệch hướng hai tuần liên tiếp, việc tiếp theo không phải là đề xuất giải pháp — mà là đi xem người dùng thật. Chi phí của bước đó tính bằng giờ; chi phí của việc bỏ qua nó tính bằng tuần.
Và một dấu hiệu cảnh báo cho chính bạn: nếu đội có thể giải thích trôi chảy vì sao người dùng rơi ra mà chưa ai xem một phiên ghi nào, lời giải thích đó là một giả định đang mặc áo kết luận.
Definition of done
- Mỗi KR chệch hướng hai tuần liên tiếp đều dẫn tới việc quan sát người dùng thật.
- Phân biệt rõ "ở đâu họ rơi ra" (số liệu) với "vì sao" (quan sát).
- Không đề xuất giải pháp trước khi có bằng chứng về nguyên nhân.
- Cột dự kiến phải đạt được dùng để báo động, không chỉ để ghi nhận.
- Cuối quý, đối chiếu giả định ban đầu với điều đã học — kể cả khi KR không đạt.
- Mỗi lời giải thích về hành vi người dùng đều truy được về một quan sát cụ thể, không phải một suy luận hợp lý.
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Product Owner | Nhận ra lúc nào cần dừng phân tích số liệu và đi xem người dùng thật |
| Business Analyst | Phân biệt "ở đâu" với "vì sao" — hai câu hỏi cần hai phương pháp khác nhau |
| Designer | Không phải vấn đề nào ở một màn hình cũng là vấn đề của màn hình đó |
| Team Lead | Ba tuần công sức mất đi vì chẩn đoán sai, không vì thực thi kém |
| Engineer | Trước khi nhận một yêu cầu "làm lại màn hình", hỏi bằng chứng nào cho thấy màn hình là vấn đề |
| QA | Phiên ghi màn hình của người dùng thật là nguồn ca kiểm thử tốt hơn mọi tài liệu |
| Founder | KR không đạt mà tìm ra nguyên nhân thật vẫn là một quý thành công — cách bạn phản ứng quyết định đội có dám báo số thật lần sau không |
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.