Greenfield MVP Launch: từ zero đến production trong 12 tuần

Greenfield MVP là dự án vui nhất mà một team có thể làm, nhưng cũng có khả năng cao nhất thất bại do over-scope. Ràng buộc là chính xác 12 tuần; scope phải đủ nhỏ để vừa vào trong đó. Case study này giới thiệu plan tuần qua tuần, kỷ luật giữ scope trung thực, và các artifact giúp MVP ship được.

Khi nào hình MVP thật sự hợp?

Có ba tín hiệu chính.

Bạn đang validate một giả thuyết. MVP tồn tại để học xem user thật có muốn cái này không. Nếu yêu cầu là "ship một hệ production ở scale", thì đó là hình dự án khác - không phải MVP.

Bạn có thể hoãn được phần engineering "thật". Multi-region, observability sâu, test toàn diện - những thứ này có thể đợi đến khi MVP chứng minh được user quan tâm.

Sponsor chấp nhận vòng phản hồi nhanh. Sponsor sẽ thấy phần mềm chạy thật trong 12 tuần và quyết liệu có đầu tư thêm không. Nếu họ muốn một plan 6 tháng với 5 phase, thì MVP không phải khung phù hợp.

Nếu bạn xây một service quan trọng phải chạy đúng từ ngày 1 (tuân thủ, payment ở scale), hãy dùng các chương lifecycle với horizon dài hơn, không phải MVP.

Cái giá khi coi MVP như dự án bình thường là gì?

Có ba kiểu lỗi thường gặp.

Scope creep thành 6 tháng. "Tiện thể..." thêm 5 tuần mỗi lần. Đến tháng thứ 4, MVP đã trở thành release v1. Tệ nhất cả hai phía: quá nhiều cho việc học nhanh, mà quá ít cho một launch thật.

Kiến trúc bị over-engineer. Microservice cho 3 endpoint, Kafka cho 100 event/ngày, multi-region cho 50 user. Cả tháng trời tốn cho platform mà MVP không cần.

Tê liệt khi quyết định. Coi mọi lựa chọn là chịu tải. Kiến trúc MVP là tạm thời theo định nghĩa; không phải mọi ADR đều đáng một giờ thảo luận.

Timeline MVP 12 tuần trông thế nào?

gantt
    title Plan MVP 12 Tuần
    dateFormat YYYY-MM-DD
    section Discovery
    Phỏng vấn stakeholder          :a1, 2026-06-21, 5d
    Kickoff doc + RACI             :a2, after a1, 3d
    section Build
    Sprint 1: auth + skeleton      :b1, 2026-07-06, 10d
    Sprint 2: tính năng cốt 1      :b2, after b1, 10d
    Sprint 3: tính năng cốt 2      :b3, after b2, 10d
    Sprint 4: persist + tích hợp   :b4, after b3, 10d
    section Beta
    Beta nội bộ (alpha)            :c1, 2026-08-31, 7d
    Beta khách thân                :c2, after c1, 7d
    section Launch
    Checklist launch + comms       :d1, 2026-09-14, 7d
    Launch công khai + monitor     :d2, after d1, 7d

Cấu trúc tàn nhẫn: 2 tuần discovery, 8 tuần build, 2 tuần launch. Bất cứ thứ gì không vừa đều hoãn sang v2.

Kickoff doc cho MVP trông thế nào?

# Kickoff MVP: {{ Tên sản phẩm }}

## Giả thuyết chúng ta đang test
{{ Một câu: user sẽ trả/dùng/đăng ký X vì lý do Y }}

## Metric thành công
{{ Cụ thể, đo được: 100 đăng ký trong 30 ngày sau launch }}

## In scope (danh sách Must, cả 5 item)
- M1: User đăng ký bằng email
- M2: User hoàn thành luồng cốt
- M3: Chúng ta charge được (nếu áp dụng)
- M4: Chúng ta thấy được hành vi họ (analytics)
- M5: Họ liên hệ được với chúng ta (form support)

## Out of scope (mọi thứ khác)
- Đa ngôn ngữ
- App mobile
- Search nâng cao
- Dashboard admin
- ...

## Kiến trúc (cố tình đơn giản)
- ASP.NET Core monolith
- PostgreSQL một instance
- Stripe cho payment
- Mailgun cho email
- Auth0 cho auth
- Không queue, không cache, không microservice

## Team
- TL/PM: {{ tên }} (60% thời gian)
- Engineer: 3 full-time
- Designer: nửa thời gian
- Sponsor: VP Product

## Plan beta
- Tuần 9: 5 user nội bộ
- Tuần 10: 20 khách thân
- Tuần 11: 100 user waitlist (launch riêng)
- Tuần 12: công khai

## Cam kết ngày
2026-09-14 launch công khai. Nếu không kịp, cắt scope thêm -
ngày là cố định.

Có hai chi tiết quan trọng. Giả thuyết và metric thành công phải rõ - đây là cái team đang đi học. Section kiến trúc ngắn, vì các lựa chọn ở đây là default cố ý; chỉ chệch khỏi default khi có lý do.

Artifact nào chạy trong phase build?

flowchart LR
    Standup[Daily standup<br/>15 phút] --> Sprint[Sprint planning<br/>2 tuần]
    Sprint --> Demo[Demo cuối sprint<br/>30 phút sponsor + team]
    Demo --> Status[Status tuần<br/>1 trang]
    Status --> Retro[Retro cuối sprint<br/>60 phút]
    Retro --> Sprint

MVP chạy các artifact lifecycle ở phiên bản nén lại: standup hàng ngày, sprint 2 tuần, kèm demo + status + retro ở cuối mỗi sprint. Demo là vũ khí bí mật - sponsor được thấy tiến độ thật mỗi 2 tuần và tin cậy tăng dần đều.

MVP scale (hay không) lên đa team ra sao?

Câu trả lời: không. MVP là single-team theo thiết kế. Nếu việc thật sự cần nhiều team, đó không phải MVP - mà là một chương trình. Hình đúng là một team xây slice MVP, các team khác đóng góp như dependency được tham vấn.

Nếu MVP thành công, sau đó chương trình mới scale: thêm team, Now/Next/Later roadmap, nhiều status report rollup. Nhưng bản thân MVP ở lại single-team.

Plan MVP có thể tự tạo ra những lỗi nào?

• Mất giả thuyết. Team quên mất vì sao đang xây cái này. Cách phòng: giả thuyết là dòng đầu tiên của mọi status report; review hàng tuần.
• Bỏ qua phát hiện từ beta. 100 user beta nói tính năng X bối rối; team vẫn launch. Cách phòng: dành cửa sổ fix-it 1 tuần giữa đóng beta và launch công khai.
• Ngày trượt một cách vô hình. Mỗi sprint trượt 2 ngày; đến tuần 10, launch đã trễ 3 tuần. Cách phòng: cắt scope tàn nhẫn ở mỗi review sprint; ngày cố định, scope linh hoạt.
• Không instrument. MVP launch mà không có analytics; team không biết được nó có chạy hay không. Cách phòng: M4 (analytics) phải trong danh sách Must, không được hoãn.

Khi nào MVP là hình sai?

Có hai trường hợp.

Đã có product-market fit. Nếu user đã dùng cái gì đó, cái kế tiếp không phải là MVP - mà là thêm tính năng với kỳ vọng stakeholder cao. Hãy dùng các chương lifecycle bình thường.

Tuân thủ hoặc an toàn-quan-trọng. Phần mềm y tế, tài chính, hạ tầng không thể ship "MVP" cắt góc. Vẫn dùng cùng các artifact kickoff/scope/launch, nhưng với timeline dài hơn và bar chất lượng đầy đủ.

Đi tiếp từ đây như thế nào?

Case study tiếp theo: hiện đại hoá legacy - hình ngược lại, một hệ cũ đang được upgrade. Sau đó, dự án quản vendor xử lý case khi phần lớn việc ở ngoài team.